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ABSTRACT 

A  software  simulator  for  the  SPHERES  formation  flight  testbed,  the  GFLOPS  SPHERES 
Simulator  (GSS),  has  been  developed.  The  Synchronized  Position,  Hold,  Engage,  and 
Reorient  Experimental  Satellites  (SPHERES)  testbed  consists  of  three  miniature  space¬ 
craft  (or  SPHERES),  each  with  their  own  power,  avionics,  navigation,  communications, 
and  propulsion.  These  spacecraft  will  operate  inside  the  International  Space  Station  to  test 
formation  flying,  autonomy,  and  autonomous  rendezvous  and  docking  algorithms.  The 
GSS  runs  on  the  Generalized  FLight  Operations  Processing  Simulator  (GFLOPS),  a  real¬ 
time  embedded  hardware  testbed  for  the  simulation  of  distributed  space  systems. 
SPHERES  flight  code  can  be  run  in  the  simulator  to  test  the  performance  of  guest  investi¬ 
gator  algorithms.  The  simulator  models  the  characteristics  of  SPHERES  hardware, 
including  thrusters  and  metrology  sensors,  and  simulates  the  dynamics  of  the  spacecraft. 
Features  include  the  ability  to  simulate  SPHERE-SPHERE  and  SPHERE-wall  collisions, 
as  well  as  docking  between  SPHERES.  A  3-D  viewer  allows  users  to  monitor  the  motion 
of  SPHERES  within  the  test  space  and  log  the  results  for  later  playback.  A  command  win¬ 
dow  allows  users  to  view  telemetry  from  the  units  and  send  them  commands.  Methods  of 
measuring  flight  code  processor  utilization  are  discussed.  Results  are  presented  from  sam¬ 
ple  simulations  that  demonstrate  the  capabilities  of  the  simulator.  Simulations  include  a 
leader-follower  control  architecture,  a  SPHERE- SPHERE  collision,  passive  docking,  and 
cooperative  docking.  Suggestions  are  given  for  future  improvements  to  the  simulator. 
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Chapter  1 

* 

INTRODUCTION 


1.1  Motivation 

A  new  class  of  satellite  system  architecture  is  being  envisioned  and  designed  that  is  funda¬ 
mentally  different  from  all  previous  ones.  It  involves  clusters  of  co-orbiting  satellites  that 
work  together  to  attain  their  desired  objectives.  This  type  of  mission  architecture  is 
known  as  a  distributed  satellite  system  (DSS).  Often  in  a  distributed  satellite  system,  the 
spacecraft  must  maintain  precise  relative  positions  with  respect  to  each  other  in  order  to 
achieve  the  desired  mission  performance.  Furthermore,  it  is  easy  to  envision  scenarios 
where  they  would  have  to  perform  a  maneuver  to  reconfigure  the  shape  or  size  of  the  clus¬ 
ter  to  respond  to  changing  conditions  or  objectives.  The  acts  of  maintaining  and  reconfig¬ 
uring  constellation  size  or  shape  are  collectively  referred  to  as  formation  flying. 

This  is  in  stark  contrast  to  the  way  that  satellites  operate  today,  where  one  large,  mono¬ 
lithic  satellite  usually  fulfills  the  entire  mission.  Even  if  the  satellite  is  part  of  a  larger  con¬ 
stellation,  such  as  a  communications  constellation,  it  is  not  orbiting  in  close  proximity  (ie. 
on  the  order  of  a  kilometer)  with  these  other  satellites,  nor  is  it  trying  to  maintain  a  precise 
relative  position  with  these  other  spacecraft. 

Formation  flying,  and  a  closely  related  area,  autonomous  rendezvous  and  docking 
between  satellites,  bring  with  them  many  inherent  challenges  and  risks.  This  is  true  when 
any  untested  and  unproven  technology  is  applied  to  space  systems.  The  situation  is  exac- 
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erbated  for  formation  flying  and  docking,  because  the  control  algorithms  being  developed 
for  DSS,  and  the  collaboration  between  spacecraft  that  will  be  necessary,  are  far  more 
complex  than  anything  that  has  been  done  in  these  areas  in  the  past.  Moreover,  the  conse¬ 
quences  of  failure  for  these  technologies  are  great,  since  failure  could  result  in  collsions 
between  multi-million  dollar  satellites  that  could  render  them  useless. 

It  is  easy  to  see  that  a  means  of  mitigating  the  risks  associated  with  DSS,  by  allowing  the 
required  technologies  to  be  tested  prior  to  deployment,  would  be  invaluable.  The  Syn¬ 
chronized  Position,  Hold,  Engage,  and  Reorient  Experimental  Satellites  (SPHERES)  test¬ 
bed,  in  development  at  the  MIT  Space  Systems  Laboratory  (SSL)  and  Payload  Systems 
Incorporated  (PSI),  will  provide  this  capability  [Miller,  2002;  Otero,  2000].  SPHERES 
consists  of  3  miniature  satellites  (or  SPHERES)  of  about  0.2  m  diameter,  that  will  operate 
inside  the  International  Space  Station  (ISS).  With  these,  it  will  be  possible  to  test  the  types 
of  algorithms  needed  for  formation  flying,  autonomy,  and  rendezvous  and  docking,  in  a 
low-risk  manner. 

The  value  of  the  SPHERES  testbed  comes  from  the  opportunity  that  it  provides  for  exter¬ 
nal  guest  scientists  to  test  their  own  algorithms  on  the  system.  This  allows  experts  in  the 
fields  of  formation  flying,  or  rendezvous  and  docking,  to  verify  their  research  on  an  actual 
system.  There  will  be  24  hours  of  experiment  time  available  on  ISS  for  the  SPHERES 
system,  spread  over  the  course  of  several  months.  It  could  take  the  form  of  twelve  two- 
hour  sessions,  eight  three-hour  sessions,  or  six  four-hour  sessions  and  will  incorporate 
tests  from  a  number  of  different  researchers  from  various  organizations  such  as  Draper 
Laboratories  and  NASA  Goddard  Space  Flight  Center.  Although  there  will  be  ample  time 
between  tests  to  analyze  results  and  make  changes  to  the  code  running  on  the  satellites,  the 
actual  experiment  time  is  very  valuable  and  cannot  be  wasted  by  testing  code  that  contains 
bugs. 

Clearly,  given  the  limited  experiment  time  allotted  to  SPHERES  on  ISS,  the  software  that 
will  run  on  the  satellites  needs  to  be  extensively  verified  before  hand.  The  best  way  to 
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verify  software  is  to  run  it  in  a  hardware-in-the-loop  simulator.  However,  a  limiting  factor 
with  space  systems  is  that  it  is  impossible  to  duplicate  long-term  zero-gravity  on  Earth. 
Therefore,  there  will  always  be  certain  types  of  algorithms  that  cannot  be  fully  tested  in  a 
hardware-in-the-loop  simulator.  A  solution  is  to  employ  a  software  simulator  that  allows 
actual  flight  code  to  be  compiled  into  the  simulator  and  tested  in  a  simulated  zero-gravity 
environment.  The  GFLOPS  SPHERES  Simulator  (GSS)  provides  just  this  capability.  It 
can  run  actual  SPHERES  flight  code,  while  simulating  the  dynamics  of  the  SPHERES 
units  and  the  characteristics  of  their  sensors  and  actuators. 

The  GFLOPS  SPHERES  Simulator  is  the  subject  of  this  thesis.  This  chapter  first 
describes  the  objectives  that  were  set  out  for  the  GSS.  It  then  provides  some  background 
on  envisioned  DSS  missions,  in  order  to  acquaint  the  reader  with  the  application  area  for 
formation  flying  and  docking  algorithms.  Further  background  on  the  SPHERES  testbed, 
including  other  methods  for  pre-flight  testing  of  SPHERES  flight  software,  follows. 
Finally,  an  outline  of  the  rest  of  the  thesis  is  given. 

1.2  Objectives 

The  idea  for  the  GSS  was  conceived  out  of  the  need  for  a  simulator  that  could  test 
SPHERES  algorithms  designed  for  a  zero-gravity,  six  degrees  of  freedom  (DOF)  environ¬ 
ment.  The  characteristics  of  thrusters  and  sensors  had  to  be  modeled  correctly,  and  the 
dynamics  of  the  system  had  to  be  accurately  represented.  In  addition,  because  rendezvous 
and  docking  would  be  investigated  with  the  SPHERES  testbed,  the  simulator  needed  to  be 
able  to  seamlessly  handle  docking  between  units.  The  GSS  was  not  seen  as  a  tool  for  the 
initial  development  of  algorithms.  This  is  more  likely  to  be  done  using  a  tool  more  ame¬ 
nable  to  rapid  prototyping,  such  as  MATLAB.  The  simulator  was  geared  towards  ensur¬ 
ing  that  the  algorithm’s  implementation  in  the  flight  code  is  correct  and  efficient.  It  was 
also  tasked  with  correctly  representing  the  timing  in  the  flight  software  and  in  the  interac¬ 
tion  of  the  units  with  other  elements  of  the  system  (such  as  metrology  beacons).  To  sup¬ 
port  these  goals,  it  was  deemed  necessary  to  be  able  to  load  actual  flight  code  into  the 
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simulator,  with  as  few  changes  as  possible.  In  order  to  investigate  the  resource  usage  of 
algorithms,  a  goal  was  set  of  being  able  to  measure  their  CPU  utilization,  as  well  as  their 
memory  usage.  Ways  were  also  needed  to  visualize  and  interpret  the  results  of  simula¬ 
tions.  State  histories  for  the  units  in  the  simulation  would  be  needed,  and  a  virtual  3-D 
viewer  that  showed  the  motion  of  satellites  in  the  test  space  was  desired  as  well. 

1.3  Distributed  Satellite  Systems 

Now  that  distributed  satellite  systems  have  been  introduced,  this  section  will  explain  some 
of  the  reasons  why  they  are  considered  such  a  promising  mission  architecture.  Some 
examples  of  planned  DSS  missions  will  also  be  presented. 

1.3.1  Satellite  Clusters 

Some  missions  can  benefit  from,  or  can  only  be  accomplished  by,  one  or  several  clusters 
of  satellites.  A  satellite  cluster  consists  of  several  satellites  flying  in  fairly  close  proximity 
(for  example,  a  cluster  with  a  1  km  radius),  possibly  with  a  high  level  of  inter-satellite  syn¬ 
chronization  and  communication,  with  payload  and  processing  shared  among  the  space¬ 
craft.  These  satellites  are  usually  required  to  maintain  precise  relative  positions. 

Perhaps  the  best  example  of  formation  flying  satellite  systems  is  separated  spacecraft 
interferometers  (SSI).  Interferometry  is  the  process  by  which  electromagnetic  waves  from 
two  or  more  apertures  are  combined,  or  interfered,  to  obtain  an  image  that  has  better  reso¬ 
lution  than  that  obtained  from  any  of  the  apertures  in  isolation.  An  SSI  consists  of  two  or 
more  imaging  satellites  that  are  separated  in  space,  yielding  the  same  angular  resolution  as 
would  be  available  from  one  large  aperture  with  a  diameter  equal  to  the  baseline  between 
the  satellites.  For  resolutions  that  require  a  baseline  of  up  to  a  kilometer,  it  is  clear  that 
this  cannot  be  accomplished  by  a  single  spacecraft,  since  raising  such  a  spacecraft  into 
orbit  would  not  be  technically  feasible.  Because  of  the  precise  optical  pathlengths  that 
must  be  maintained  in  SSIs,  precise  position  and  attitude  control  is  required. 


Distributed  Satellite  Systems 


19 


1.3.2  Benefits  of  Distribution 

Besides  the  fact  that  they  can  enable  missions  that  would  otherwise  be  impossible,  there 
are  several  other  compelling  benefits  to  using  satellite  clusters  to  perform  a  mission 
[AFRL,  2002].  The  distributed  architecture  makes  it  less  vulnerable  to  failure.  As  long  as 
the  cluster  is  designed  to  avoid  single-point  failures,  by  distributing  critical  functions 
across  the  cluster,  the  mission  can  still  survive  if  one  or  more  satellites  cease  functioning, 
although  the  overall  performance  will  likely  decrease.  This  graceful  degradation,  and  the 
possibility  to  reconfigure  the  cluster  upon  failures,  greatly  increases  reliability.  Adaptabil¬ 
ity  is  also  improved  by  allowing  for  the  possibility  of  launching  additional  satellites,  per¬ 
haps  with  new  instruments,  that  can  interoperate  with  the  existing  spacecraft.  In  this  way, 
future  technical  advances  can  be  incorporated  cheaply  instead  of  having  to  redesign  the 
entire  system,  and  the  cluster  can  be  upgraded  easily  over  time.  Even  with  an  existing 
cluster,  we  can  modify  the  cluster  geometry  to  obtain  different  performance.  This  is  par¬ 
ticularly  beneficial  for  imaging  missions.  Furthermore,  manufacturing  cost  is  decreased 
because  of  the  savings  brought  about  by  mass  producing  several  similar  satellites. 

1.3.3  Future  DSS  missions 

Several  DSS  missions  are  planned  over  the  next  decade.  Some  are  merely  in  the  planning 
stage,  while  others  are  already  in  development.  Some  of  these  missions  will  now  be  dis¬ 
cussed. 

Starlight 

Starlight  is  a  NASA  mission  being  developed  at  the  Jet  Propulsion  Laboratory  (JPL),  with 
a  proposed  launch  date  of  July  2006  [JPLA,  2002].  Starlight  will  serve  to  develop  and  test 
several  new  technologies  and  will  be  a  precursor  to  future  NASA  missions.  It  will  be  the 
first  spacebome  stellar  interferometer  and  will  consist  of  two  telescopes  on  two  spacecraft 
that  will  be  separated  by  a  distance  of  40  -  600  m.  The  satellites  will  be  required  to  main¬ 
tain  their  separation  to  within  less  than  1  cm  and  their  angular  bearing  to  within  3arcmin. 
The  formation  flying  for  this  mission  will  take  the  form  of  a  master/slave  scenario,  where 
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the  slave,  the  smaller  "collector"  spacecraft  will  adjust  its  position  and  attitude  in  response 
to  the  motion  of  the  larger  "combiner"  spacecraft.  Autonomous  formation  flying  will  be 
tested  and  specific  stars  will  be  imaged.  Figure  1.1  shows  the  two  Starlight  spacecraft  in 


Figure  1.1  Starlight  mission. 


operation. 

Terrestrial  Planet  Finder 

Terrestrial  Planet  Finder  (TPF)  will  take  the  process  of  imaging  planets  even  further.  It 
will  study  many  characteristics  of  planets  as  far  away  as  50  light  years,  including  their 
chemistry,  in  order  to  determine  which  planets  have  the  right  chemistry  to  support  life. 
This  will  consist  of  measuring  the  relative  amounts  of  gases  such  as  carbon  dioxide,  water 
vapour,  ozone  and  methane.  TPF  will  also  study  how  planets  form  from  disk  material 
around  new  stars.  These  goals  will  require  four  telescopes  of  3.5  m  diameter,  with  a  base- 
*  line  of  75  -  1000  m  [JPLB,  2002],  as  depicted  in  Figure  1.2. 

TechSat  21. 

The  United  States  Air  Force  is  developing  a  distributed  sparse  aperture  radar  system  for 
ground  and  air  moving  target  indication  (GMTI/AMTI)  known  as  TechSat  21  [AFRL, 
2002],  As  can  be  seen  from  Figure  1.3,  this  system  will  be  Earth-looking,  in  contrast  to 
the  systems  described  so  far  that  peer  into  space.  A  flight  experiment  with  three  space¬ 
craft  is  projected  for  2004,  while  a  much  more  extensive  operational  system  will  follow  in 
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Figure  1.2  Terrestrial  Planet  Finder. 


Figure  1.3  TechSat  21 . 


the  future.  TechSat  21  will  feature  extensive  inter-satellite  communication  and  complex 
formation  flying.  Because  the  clusters  will  be  orbiting  around  the  Earth,  instead  of  resid¬ 
ing  far  away  from  Earth  like  the  previous  systems  described,  it  will  have  to  counter  the 
gravitational  disturbances  caused  by  the  fact  that  the  Earth  is  not  a  perfect  sphere.  Also, 
because  TechSat  21  will  be  multi-mission  capable,  the  cluster  will  have  to  be  able  to  resize 
itself  efficiently  to  adapt  to  different  mission  scenarios 

Orbital  Express 

Another  scenario  that  is  being  considered  for  the  future  is  that  of  satellites  that  can  rendez¬ 
vous  and  dock  autonomously.  This  could  allow  for  the  possibility  of  on-orbit  refueling  as 
satellites  run  out  of  propellant,  and  for  hardware  reconfiguration  of  satellites  by  switching 
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out  the  components  of  a  satellite.  One  possibility  is  to  have  a  robotic  vehicle  that  moves 
between  orbiting  fuel  depots  and  the  satellites  that  it  services.  The  Defense  Advanced 
Research  Projects  Agency  (DARPA)  has  envisioned  such  a  system,  known  as  an  Autono¬ 
mous  Space  Transporter  and  Robotic  Orbiter  (ASTRO)  [DARPA,  2002],  Its  Orbital 
Express  Space  Operations  Architecture  program  will  seek  to  demonstrate  these  capabili¬ 
ties  with  prototype  technologies  by  2004  and  a  working  system  by  2010. 

1.4  SPHERES 

1.4.1  Project  Description 

The  SPHERES  testbed  will  allow  for  cost-effective  testing  of  algorithms  for  formation 
flying,  autonomy,  and  rendezvous  and  docking.  The  3  miniature  satellites  that  make  up 
the  testbed  each  have  their  own  power,  on-board  computer,  navigation,  propulsion  and 
communications.  Therefore,  they  will  be  able  to  move  around  the  ISS,  calculate  their 


1.  Reproduced  from  GSP  Interface  Document  [HilstadA,  2002]. 
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positions  and  orientations,  execute  control  algorithms,  and  send  commands  or  telemetry  to 
each  other.  Figure  1.4  shows  a  computer  generated  view  of  a  SPHERE.  Other  compo¬ 
nents  of  the  system  include  a  laptop  for  user  interaction  with  the  satellites,  and  five  ultra¬ 
sound  transmitter  beacons  that  are  placed  around  the  test  space.  The  beacons  allow  for 
state  determination  based  on  the  ranges  between  each  beacon  and  a  number  of  ultrasound 
receivers  onboard  the  satellites.  The  satellites  are  designed  to  eventually  operate  semi- 
autonomously  in  the  zero-gravity  environment  inside  the  International  Space  Station.  The 
operational  environment  will  roughly  take  the  form  of  a  cube  with  side  length  of  six  feet, 
although  operation  in  a  space  of  up  to  10’ x  10’ x  10’ is  possible.  Figure  1.5  depicts  a  typi¬ 
cal  test  session.  Commands  are  uploaded  to  the  satellites  wirelessly  from  a  laptop,  and  the 
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Figure  1.5  Typical  Spheres  Test  Session1. 

1.  Reproduced  from  SPHERES  CDR  presentation,  Feb.  15,  2002  [Miller,  2002]. 


satellites,  which  are  able  to  determine  their  own  position  and  orientation,  fire  appropriate 
thrusters  to  maintain  some  formation  flying  configuration,  or  perform  some  maneuver. 
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All  the  while,  the  satellites  communicate  with  each  other  wirelessly,  and  send  state  and 
debug  data  to  the  laptop.  This  data  can  then  be  sent  back  down  to  Earth  after  the  test  ses¬ 
sion.  Interaction  by  astronauts  will  consist  of  starting  each  test  by  arranging  the 
SPHERES  and  turning  them  on,  sending  commands  from  the  laptop,  and  replenishing 
consumables  (batteries  and  propellant). 

The  SPHERES  project  began  as  a  three-term  project  design  course  for  undergraduates  in 
the  Department  of  Aeronautics  and  Astronautics  at  MIT  in  1998  and  was  transferred  to 
graduate  students  once  the  course  was  over  and  the  prototype  hardware  had  been  built  and 
its  operational  capabilities  verified.  Since  that  time,  graduate  student  researchers  have 
been  refining  the  control,  communication,  and  metrology  algorithms  used  in  the  system. 
Now,  PSI  is  designing  and  building  an  improved  set  of  hardware  for  the  operational  sys¬ 
tem  to  be  used  on  ISS.  SPHERES  will  allow  high-risk  algorithms  to  be  tested,  verified 
and  improved  before  implementing  them  on  complex  satellites  that  cost  tens  or  hundreds 
of  millions  of  dollars. 

1.4.2  Testing  Environments 

The  SPHERES  software  and  hardware  needs  to  be  extensively  verified  prior  to  its  use  on 
ISS.  Besides  the  GSS,  there  are  several  other  ways  of  doing  this,  each  with  its  advantages 
and  disadvantages.  These  verification  environments  will  now  be  discussed. 

Three  DOF  Air  Table 

MIT  SSL  has  an  air-table  setup  that  allows  for  3  degrees  of  freedom  (DOF)  testing  of  the 
SPHERES  units.  To  operate  on  the  table,  the  SPHERE  is  placed  on  a  carriage  that  has 
three  air  pucks  on  the  bottom,  arranged  in  an  equilateral  triangle.  Three  canisters  of  com¬ 
pressed  C02  or,  alternatively,  a  flexible  hose  providing  compressed  air,  create  a  layer  of 
gas  between  the  air  pucks  and  the  table,  allowing  for  nearly  frictionless  translation  and 
rotation.  In  this  way,  the  SPHERE  is  allowed  to  translate  in  two  directions  along  the  1 .25 
m  x  1.25  m  glass  surface,  and  rotate  around  one  axis.  This  is  an  inexpensive  way  to  test 
SPHERES  hardware  as  well  as  simple  algorithms  that  do  not  depend  on  full  6  DOF 
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motion.  A  SPHERES  unit  can  also  be  hung  by  a  string  above  the  table  to  verify  correct 
state  determination  in  three  dimensions.  The  air  table  testing  environment  is  accessible  at 
all  times  by  the  MIT  SPHERES  team,  allowing  for  iterative  development,  with  immediate 
testing  and  verification  of  new  code.  However,  with  only  3  DOF,  it  is  not  possible  to  test 
more  complex  algorithms.  There  are  also  some  disturbances  present  in  this  setup  that  are 
not  expected  in  the  ISS  operational  environment.  Imperfections  in  the  table  surface  and 
build-up  of  material  on  the  surface  cause  friction,  while  misalignment  of  the  surface  nor¬ 
mal  with  the  gravity  vector  causes  a  constant  drift. 

Johnson  Space  Center  Reduced  Gravity  Program 

Another  testing  environment  that  has  been  used  is  the  Reduced  Gravity  Program  at 
NASA’s  Johnson  Space  Center  in  Houston,  Texas.  This  program  utilizes  a  specially  mod¬ 
ified  KC-135A  turbojet  transport  (similar  to  a  Boeing  707)  performing  parabolic  arcs  to 
create  20  -  25  second  weightless  periods.  A  typical  flight  lasts  for  2  -  3  hours  and  consists 
of  30  -  40  parabolas.  Figure  1 .6  shows  the  gravity  experienced  at  different  points  in  a  typ¬ 
ical  parabolic  maneuver.  Further  information  can  be  obtained  from  the  JSC  Reduced 
Gravity  Program  website  [JSC,  2002].  These  flights  allow  for  verification  of  the  opera¬ 
tion  of  hardware  in  micro-g,  as  well  as  investigation  of  the  performance  of  algorithms  in  6 
DOF.  However,  the  fact  that  each  weightless  period  lasts  for  only  25  seconds  limits  the 
length  of  the  tests  that  can  be  performed.  Also,  turbulence  affects  the  relative  motion  of 
the  SPHERES  inside  the  frame  of  reference,  and  since  the  nose  of  the  plane  goes  from 
pointing  up  45°  to  pointing  down  45°  during  the  weightless  period,  the  frame  of  reference 
rotates  90°  during  this  time.  These  effects  limit  the  fidelity  of  tests  that  can  be  performed 
in  the  KC-135.  Another  troublesome  factor  is  that  team  members  in  close  proximity  to  the 
SPHERE  who  are  helping  to  perform  tests  affect  the  measurements  used  by  the  SPHERE 
to  sense  its  position  and  attitude.  As  will  be  explained  later,  these  measurements  rely  on 
ultrasound  pulses  that  propagate  to  the  SPHERE  from  transmitter  beacons  placed  inside 
the  test  environment.  Blockage  of  these  waves  by  team  members  affects  the  results  of 
experiments.  This  problem  will  be  less  severe  on  the  ISS  since  the  continuous  zero-grav- 
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Figure  1.6  Gravity  experienced  during  parabolic  maneuver  by  KC-135. 


ity  will  mean  that  astronauts  will  not  have  to  be  in  close  proximity  to  catch  the  SPHERES 
units  every  25  s.  But  the  most  significant  factor  affecting  the  usefulness  of  the  Reduced 
Gravity  Program  is  that  flights  by  the  SPHERES  team  occur  only  a  few  times  a  year. 
Therefore,  the  limited  availability  of  this  test  environment  means  that  it  cannot  be  used  for 
regular  and/or  unexpected  testing  and  verification  of  SPHERES  software.  It  is  primarily 
useful  for  validation  of  hardware. 

1.4.3  Software  Simulators 

Since  the  SPHERES  hardware  is  not  likely  to  change  after  the  new  hardware  is  intro¬ 
duced,  the  above  testing  environments  are  adequate  for  verifying  the  operation  of  hard¬ 
ware.  Some  portions  of  the  software  are  likely  to  remain  static  as  well.  However,  many 
critical  software  functions,  such  as  control  algorithms,  will  be  modified  regularly,  and  will 
even  be  switched  with  completely  new  code.  This  is  unavoidable  due  to  the  nature  of  the 
guest  scientist  program,  which  is  designed  to  let  separate  investigators  test  independent 
algorithms  that  they  design.  We  have  seen  that  the  above  two  test  environments  are  not 
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adequate  for  validating  SPHERES  code.  The  lg  testbed  can  only  test  the  3  DOF  perfor¬ 
mance  of  algorithms,  while  the  KC-135  test  environment  is  plagued  by  limited  flights  and 
other  problems.  Clearly,  there  is  a  need  for  the  capability  to  test  code  developed  for  the 
testbed  on  a  regular  basis,  in  a  manner  that  closely  represents  the  characteristics  of  the  ISS 
operating  environment.  Since  there  is  no  feasible  way  of  simulating  a  zero-g  environment 
with  the  real  hardware  (other  than  on  the  KC-135),  then  a  software  simulator  is  the  only 
way  to  fully  test  code  developed  for  SPHERES.  A  software  simulator  can  easily  simulate 
a  zero-g  environment  and  is  highly  accessible  for  testing.  The  SPHERES  Guest  Scientist 
Program  (GSP)  provides  two  software  simulators  for  guest  investigators. 

GSP  Simulation 

The  GSP  simulation,  developed  by  Mark  Hilstad,  is  intended  to  aid  initial  code  develop¬ 
ment  by  guest  scientists.  It  is  described  in  detail  in  the  SPHERES  GSP  Interface  [Hil- 
stadA,  2002].  It  includes  the  ANSI  C  source  code  files  that  make  up  the  SPHERES 
software  framework,  into  which  the  investigator’s  algorithms  are  added.  The  only  change 
made  to  these  files  is  that  some  of  the  low-level  functions  that  access  hardware  have  been 
modified.  The  GSP  simulation  is  meant  to  allow  investigators  to  check  that  their  code 
compiles  into  the  SPHERES  software  framework,  and  to  verify  basic  operations  in  a  low- 
fidelity  simulation  (either  1-g  or  0-g).  Guest  investigators  should  be  able  to  accomplish 
these  objectives  without  interaction  with  the  SPHERES  team.  The  output  of  the  GSP  sim¬ 
ulation  is  a  DAT  file  that  contains  state  histories  and  debug  info.  A  MATLAB  m-function 
is  provided  that  can  read  this  DAT  file  and  plot  state  histories  and  the  histories  of  quantita¬ 
tive  debug  variables. 

GFLOPS  SPHERES  Simulator 

The  other  simulator  is  the  GFLOPS  SPHERES  Simulator,  the  subject  of  this  thesis.  The 
Generalized  FLight  Operations  Processing  Simulator  (GFLOPS)  is  a  testbed  that  consists 
of  hardware  and  associated  software  that  was  designed  for  real-time  distributed  satellite 
system  simulations.  Located  in  the  MIT  Space  Systems  Laboratory,  it  consists  of  eight 
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networked  PowerPC  single-board  computers  running  the  OSE  real-time  operating  system. 
Actual  SPHERES  code,  with  minor  modifications,  can  be  run  on  these  computers.  The 
GFLOPS  SPHERES  Simulator  propagates  the  dynamics  of  the  SPHERES  satellites  and 
provides  metrology  information  to  the  SPHERES.  It  allows  for  simulation  of  motion  in  6- 
DOF,  in  a  0-g  (free-flying)  or  1-g  (air  table)  environment,  with  multiple  satellites.  Noise 
can  be  added  to  thruster  firings  or  metrology  readings  in  order  to  better  approximate  the 
actual  SPHERES  operational  environment.  Alternatively,  the  satellites  can  be  provided 
with  perfect  state  knowledge  to  investigate  the  performance  of  a  formation  flying  algo¬ 
rithm  under  best-case  conditions.  The  simulator  can  provide  debug  data  and  state  histories 
from  test  runs.  Furthermore,  a  viewer  allows  the  results  of  test  runs  to  be  visualized  in  a  3- 
D  environment  on  a  PC,  either  as  the  simulation  progresses,  or  later  in  a  playback  mode. 
The  simulator  also  allows  for  commands  to  be  sent  to  the  satellites  from  a  PC,  just  as  in  an 
actual  operational  scenario.  An  advantage  of  this  simulator  is  that  its  real-time  nature 
allows  for  better  representation  of  the  timing  and  interrupts  of  the  actual  SPHERES  sys¬ 
tem  than  the  GSP  simulation. 

The  four  components  of  the  SPHERES  Guest  Scientist  Program  are  depicted  in 
Figure  1.7.  The  KC-135  tests  are  not  considered  part  of  the  program  since  they  occur  too 
infrequently  and  are  used  primarily  for  hardware  verification.  The  accessibility  and  fidel¬ 
ity  of  the  various  elements  of  the  program  vary  inversely.  The  software  simulators  located 
at  the  top  of  the  figure  are  suitable  for  less  mature  algorithms,  where  we  want  to  investi¬ 
gate  the  general  performance  of  the  algorithm,  to  verify  that  nothing  goes  catastrophically 
wrong.  At  this  stage  of  development,  a  realistic  disturbance  environment  is  not  necessary 
and  may  even  decrease  the  usefulness  of  tests.  We  desire  high  accessibility  to  the  testing 
environment  at  this  point,  because  of  the  iterative  nature  of  the  early  stages  of  algorithm 
development.  The  air  table  and  the  Space  Station  testing  environments  have  much  more 
fidelity,  but  they  are  less  accessible  for  testing.  The  air  table  requires  the  time  of 
SPHERES  team  members,  while  the  ISS  testing  is  limited  to  24  hours  of  total  operations. 
They  are  not  as  conducive  to  the  initial  algorithm  development  and  testing  needs  of  guest 
scientists.  However,  for  mature  algorithms  that  can  be  tested  in  3  DOF,  the  air  table  is  a 
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Figure  1.7  Guest  Scientist  Program  components. 


Figure  1.8  GSP  testing  sequence. 


valuable  verification  environment  since  it  allows  testing  with  actual  SPHERES  units. 
This  is  essential  for  refining  control  parameters  that  depend  on  the  precise  characteristics 
of  the  SPHERES  units.  Figure  1 .8  illustrates  the  iterative  nature  of  testing  within  the  GSP 
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program.  While  testing  begins  at  the  GSP  Simulation  for  a  particular  algorithm,  it  can 
progress  from  there  through  any  path  through  the  various  GSP  elements.  Data  from  test¬ 
ing  on  the  International  Space  Station  can  even  be  used  to  refine  algorithms  for  future  ses¬ 
sions. 


1.5  Outline  of  Thesis 

This  thesis  provides  a  comprehensive  description  of  the  GFLOPS  SPHERES  simulator. 
Chapters  2  and  3  contain  essential  background  information.  First,  Chapter  2  gives  a 
detailed  description  of  the  SPHERES  formation  flying  testbed.  This  discussion  is  very 
important  because  it  outlines  those  features  of  the  SPHERES  hardware  that  are  modeled  in 
the  simulator,  as  well  as  the  software  that  must  run  in  the  simulator.  Then,  Chapter  3 
describes  both  the  hardware  and  software  that  make  up  GFLOPS,  the  real-time  distributed 
spacecraft  simulation  testbed  on  which  the  simulator  operates.  Chapter  4  is  the  main  sec¬ 
tion  in  the  thesis.  It  describes  each  of  the  software  modules  that  make  up  the  simulator,  as 
well  as  the  overall  architecture  into  which  they  fit.  It  yields  a  thorough  understanding  of 
the  design  and  operation  of  each  of  these  modules,  as  well  as  their  interfaces  with  each 
other.  Chapter  4  also  gives  an  account  of  ways  that  we  can  investigate  the  use  of 
resources,  such  as  processing  time  or  memory,  by  SPHERES  flight  code  running  on  the 
simulator.  Chapter  5  contains  simulation  results  that  have  been  obtained  thus  far.  Several 
simulations  were  performed,  providing  insight  into  the  uses  of  the  simulator,  and  its  accu¬ 
racy  in  representing  the  SPHERES  testbed.  Finally,  Chapter  6  sums  up  the  work  that  has 
been  accomplished  thus  far,  puts  it  into  context,  and  provides  suggestions  for  future  work 
that  could  further  improve  the  effectiveness  and  accuracy  of  the  GFLOPS  SPHERES  sim¬ 
ulator. 


Chapter  2 
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2.1  Introduction 

This  chapter  describes  the  SPHERES  formation  flying  testbed  in  detail.  Since  this  is  what 
we  are  trying  to  simulate,  it  is  important  to  have  a  good  understanding  of  the  SPHERES 
hardware  and  software.  We  begin  by  examining  the  types  of  control  architectures  that  can 
be  implemented  with  SPHERES.  Then  each  of  the  SPHERES  subsystems  is  discussed, 
with  emphasis  on  the  details  that  are  modeled  or  implemented  in  the  GFLOPS  SPHERES 
Simulator. 

2.2  Testing  Scenarios 

There  are  several  testing  configurations  that  are  available  with  the  SPHERES  testbed 
[Miller,  2002], 

•  Independent  Control:  With  a  single  satellite,  we  can  investigate  long-term 
station-keeping,  as  well  as  minimum  propellant  maneuvers  involving  rota¬ 
tions,  translations,  or  both.  These  same  maneuvers  can  also  be  done  in 
multi-satellite  tests.  Each  satellite  determines  its  control  actions  based  solely 
on  information  about  its  state  and  its  objectives. 

•  Master/Slave  Control:  We  can  have  a  master/slave  control  scheme,  where 
the  "master"  satellite  receives  the  state  information  from  all  satellites  and 
decides  on  the  action  for  each  of  them  to  take.  The  "slaves"  simply  send 
state  data  to  the  master  and  receive  commands  in  return,  performing  no  con¬ 
trol  law  computation  themselves. 
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•  Leader-follower  control:  This  involves  the  leader  sending  its  state  to  the 
follower  satellites.  The  followers  attempt  to  track  the  leader’s  state,  with 
some  offset  to  avoid  collisions. 

•  Distributed  control:  Distributed  control  is  more  complex,  with  each  satel¬ 
lite  having  knowledge  of  the  state  of  all  the  others,  and  determining  its  own 
motion  based  on  this  information. 

These  forms  of  control  can  be  used  to  test  a  wide  range  of  algorithms,  including  ones  for 
autonomous  rendezvous  and  docking,  collision  avoidance,  and  fuel  balancing  maneuvers. 
Retargeting  and  image  plane  filling  maneuvers  can  also  be  performed. 


2.3  Physical  Properties 

The  physical  properties  of  a  SPHERES  unit  are  not  the  same  on  the  laboratory  air  table 
and  in  micro-gravity.  The  reason  for  this  is  that  on  the  air  table,  the  carriage  on  which  the 
unit  rests  must  be  considered  part  of  the  SPHERE  when  measuring  its  physical  properties. 
This  affects  the  mass  of  the  SPHERE,  as  well  as  its  inertia  matrix.  The  mass  and  inertia 
properties  of  a  prototype  SPHERE  [HilstadA,  2002]  are  given  in  Table  2.1,  for  the  6-DOF 

TABLE  2.1  Mass  and  inertia  properties  of  prototype  SPHERE  for  6-DOF  configuration. 


Property 

-  Value 

Accuracy 

Mass 

3.4447  kg 

±  0.001  kg 

Inertia  (body  x-axis) 

0.0204  kg  m2 

±5% 

Inertia  (body  y-axis) 

0.0170  kg  m2 

±  5  % 

Inertia  (body  z-axis) 

0.0190  kg  m2 

±5% 

TABLE  2.2  Mass  and  inertia  properties  of  prototype  SPHERE  for  air  table  configuration. 


Property 

Value  Accuracy 

Mass 

Inertia  (body  z-axis) 

5.5299  kg  ±0.001  kg 

0.0311  kg  m2  ±5% 

configuration,  and  in  Table  2.2  for  the  air  table  configuration.  Values  for  the  flight 
SPHERES  were  not  available  at  the  time  of  publishing  of  this  thesis. 
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2.4  Subsystems 

A  SPHERES  unit  consist  of  six  main  subsystems:  power,  software,  communications, 
metrology,  avionics,  and  propulsion.  These  will  now  be  described.  The  SPHERES  Criti¬ 
cal  Design  Review  [Miller,  2002]  is  a  good  source  for  more  information  about  power, 
metrology,  avionics  and  propulsion.  More  in-depth  discussion  about  communications  can 
be  found  in  [Otero,  2000],  while  the  best  sources  for  software  and  metrology  are  [Hil- 
stadB,  2002],  and  the  GSP  Interface  Document  [HilstadA,  2002]. 

2.4.1  Power 

The  power  subsystem  consists  of  two  AA  alkaline  battery  packs  that  provide  the  power 
that  drives  the  operation  of  a  SPHERES  unit.  The  power  subsystem  is  not  modeled  in  the 
GFLOPS  SPHERES  Simulator. 

2.4.2  Software 

The  SPHERES  flight  software  runs  on  a  basic  operating  system  with  hardware  support 
functions.  There  are  three  different  frameworks  within  which  guest  scientists  can  organize 
their  code.  The  Standard  Control  Interface  is  the  most  easy  to  use.  It  is  made  up  of 
three  main  interrupts  (propulsion,  communications,  and  control)  as  well  as  background 
processing.  When  employing  the  Standard  Control  Interface,  the  guest  scientist  makes 
changes  only  to  the  control  interrupt.  This  interrupt  consists  of  standard  code  blocks  with 
predefined  inputs  and  outputs  that  must  be  adhered  to.  The  programmer  simply  inserts 
custom  control  code  within  the  predefined  blocks,  and/or  calls  functions  previously  coded 
by  the  SPHERES  team.  This  process  is  designed  to  avoid  modifications  to  the  basic  oper¬ 
ation  of  the  interrupt,  thereby  minimizing  errors  in  timing  or  interaction  with  other  inter¬ 
rupts. 

The  Direct  Control  Interface  involves  the  replacement  of  the  controller  interrupt  code 
and/or  background  processing  code  with  custom  logic.  It  places  no  real  restrictions  on  the 
custom  code.  Therefore,  it  can  be  quite  different  from  the  Standard  Interface,  with  simi- 
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larities  existing  only  in  the  timing  and  general  purpose  of  the  interrupts.  Thus,  the  Direct 
Interface  provides  strong  flexibility  to  investigators.  However,  it  requires  them  to  attain  a 
high  level  of  understanding  of  the  SPHERES  software,  especially  with  respect  to  the  inter¬ 
actions  between  interrupts. 

The  Custom  Control  Interface  places  essentially  no  restrictions  on  the  SPHERES  soft¬ 
ware.  The  number,  purpose,  and  timing  of  the  interrupts  can  be  changed,  affording  excep¬ 
tional  freedom  to  the  investigator. 

The  four  interrupts  that  make  up  the  Standard  Control  Interface  will  now  be  described. 


Figure  2.1  Custom  Control  Interface.1 
1.  Figure  courtesy  of  Mark  Hilstad. 


Figure  2.1  shows  the  relationships  between  the  various  interrupts  and  functions  of  the 
Standard  Control  Interface. 
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Propulsion  Interrupt 

The  highest  priority  interrupt  is  the  propulsion  interrupt  (or  thruster  interrupt),  which  runs 
at  1  kHz.  This  interrupt’s  main  objective  is  to  determine  whether  to  turn  each  thruster  on 
or  off,  which  is  decided  by  checking  a  global  array  that  holds  the  time  remaining  for  the 
current  pulse  of  each  thruster.  The  pulse  times  for  the  thrusters  are  set  in  the  controller 
interrupt.  These  times  are  decremented  each  time  through  the  thruster  interrupt,  until  they 
reach  zero  and  the  thruster  is  turned  off.  The  thruster  interrupt  also  ensures  that  all  thrust¬ 
ers  are  turned  off  when  the  satellite  is  receiving  global  metrology,  since  the  ultrasonic 
noise  produced  by  the  thrusters  can  impair  global  metrology  readings.  Further  tasks  of  the 
thruster  interrupt  include  incrementing  time,  battery  and  fuel  usage  counters,  and  sending 
requests  for  new  global  metrology  information  at  a  set  period,  usually  500  ms.  Because  of 
the  1kHz  period  of  the  interrupt,  there  is  a  1  ms  pulse- width  resolution  for  the  propulsion 
system. 

Communications  Interrupt 

The  second  highest  priority  interrupt  is  the  communications  interrupt.  This  is  not  a  timed 
interrupt.  It  executes  only  when  communications  data  becomes  available.  It  then  fetches 
the  data,  checks  its  source,  and  places  it  in  the  appropriate  global  array  according  to  its 
source  (laptop,  other  satellite  or  global  metrology  reading),  so  that  it  can  be  accessed  by 
the  other  interrupts. 

Controller  Interrupt 

The  controller  interrupt  runs  at  the  lowest  priority.  It  can  run  at  any  integer  frequency  up 
to  25  Hz,  but  usually  runs  at  10  Hz.  The  reason  for  the  maximum  frequency  of  25  Hz  is 
that  heat  dissipation  concerns  in  the  thrusters  limit  the  pulse-width  frequency  and  hence 
the  control  frequency  [HilstadA,  2002].  The  controller  interrupt  runs  the  desired  control 
algorithm  and  determines  the  lengths  of  thruster  pulses.  It  also  processes  communications 
received  from  other  satellites  and  creates  telemetry  data  that  is  ready  to  be  sent  to  other 
satellites  or  ground.  Intersatellite  communication  is  important  for  leader/follower  archi- 
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tectures,  where  the  follower  needs  to  know  the  state  of  the  leader  so  that  it  can  attempt  to 
follow  it. 

Background  Processing 

Whenever  none  of  the  above  interrupts  are  executing,  background  processing  occurs. 
This  consists  of  processing  the  communications  data  from  the  laptop  that  was  placed  into 
global  arrays  in  the  communications  interrupt,  sending  communications  (of  data  usually 
created  in  the  controller  interrupt)  to  other  satellites  or  ground,  performing  housekeeping 
tasks  (such  as  checking  battery  and  propellant  tank  levels),  and  running  the  position  and 
attitude  determination  routine  that  processes  metrology  information  to  determine  the  satel¬ 
lite’s  state. 

2.4.3  Communications 

Communications  in  the  SPHERES  testbed  consists  of  two  wireless  data  transmission 
modes:  satellite-to-satellite  (STS)  and  satellite-to-laptop  (STL).  These  occupy  different 
communication  channels,  with  the  STS  operating  at  916.5  MHz  and  the  STL  at  868.35 
MHz.  While  these  channels  are  bi-directional,  they  are  half-duplex,  meaning  that  only 
one  unit  can  transmit  at  a  time.  Additionally,  when  a  message  is  sent,  it  is  received  by 
each  of  the  units.  They  must  determine  for  themselves  if  the  message  is  intended  for  them 
by  looking  at  the  destination  information  sent  along  with  the  message.  To  ensure  that  only 
one  unit  transmits  at  a  time,  token  ring  networks  are  used  (one  for  STS,  another  for  STL). 
These  operate  through  the  passing  of  a  token  around  the  network  and  the  stipulation  that  a 
unit  can  only  transmit  when  it  holds  the  token. 

Communications  is  in  the  form  of  packets.  A  packet  consists  of  a  header,  the  data,  and  a 
tail  as  depicted  in  Figure  2.2.  Packets  are  divided  into  bytes.  The  start  byte  signals  the 
start  of  a  new  packet.  The  to  field  specifies  the  intended  recipient  of  the  data  and  is  used 
by  units  to  check  if  a  message  was  intended  for  them.  The  from  field  denotes  the  sender  of 
the  message,  while  type  signifies  whether  it  is  a  command,  telemetry,  or  token  message, 
and  size  refers  to  the  number  of  bytes  contained  in  the  data  section.  The  tail  consists  of 


Subsystems 


37 


start 

to 

from 

type 

start 

timel 

time2 
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data 
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Figure  2.2  Packet  configuration. 


two  checksum  bytes,  one  representing  the  upper  eight  bits  of  the  checksum,  and  the  other 
the  lower  eight  bits.  The  checksum  will  be  equal  to  the  sum  of  all  data  in  the  message, 
otherwise  an  error  has  occurred  in  the  transmission.  The  packet  is  broken  up  into  eight  bit 
pieces  that  are  transmitted  separately.  Commands  are  acknowledged  in  their  entirety,  and 
a  good  acknowledgment  results  in  the  sending  of  a  GO  command  to  instruct  the  com¬ 
manded  satellite  to  execute  the  command.  If  proper  acknowledgment  is  not  received,  the 
command  is  resent.  Telemetry  takes  the  form  of  state  and  non-critical  error  information 
and  is  not  acknowledged.  That  is,  telemetry  data  that  has  a  checksum  error  is  simply 
thrown  away. 

2.4.4  Metrology 

The  metrology  subsystem  enables  the  SPHERES  units  to  maintain  knowledge  of  their 
state.  The  state  of  a  SPHERES  unit  consists  of  its  position  and  velocity  with  respect  to  the 
global  frame,  orientation  within  this  frame  (expressed  via  a  four-element  quaternion),  and 
angular  rotation  rates  about  its  three  body  axes.  There  are  two  metrology  systems  that 
enable  determination  of  this  state.  While  they  each  could  theoretically  operate  by  them¬ 
selves,  they  are  used  in  combination. 

The  inertial  measurement  unit  (IMU)  consists  of  a  3 -axis  accelerometer  and  three  single¬ 
axis  rate  gyroscopes.  All  of  these  are  aligned  with  the  body  axes  defined  for  the  SPHERE. 
By  integrating  the  output  of  the  accelerometer,  the  velocity  and  position  of  the  unit  can  be 
recovered,  while  the  rate  gyro  can  yield  the  angular  velocity  and  orientation.  However, 
due  to  the  double  integration,  the  accelerometer,  by  itself,  can  maintain  reasonably  accu¬ 
rate  position  information  for  only  about  two  seconds,  while  the  rate  gyros  are  useful  for 
approximately  20  minutes  of  independent  operation  [Otero,  2000].  The  performance 
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specifications  for  the  Honeywell  Q-Flex  accelerometer  are  given  in  Table  2.3,  while  those 
for  the  BEI  Gyrochip  II  rate  gyros  are  given  in  Table  2.4  [Miller,  2002]. 

TABLE  2.3  Honeywell  Q-Flex  accelerometer  performance  specifications. 


Input  Range 

±20  g 

Bias 

<20  mg 

Scale  factor 

2.75  mA/g±1.8% 

Threshold  and  resolution 

<5  tig 

Bandwidth 

<200  Hz 

Noise 

0  to  10  Hz 

10  to  500  Hz 

20  fig  RMS 

200  tig  RMS 

RSS  bias  and  scale  factor 
one-year  repeatability 

1  mg 

Operating  temperature 

-40  to  160°C 

TABLE  2.4  BEI  Gyrochip  II  performance  specifications. 


Input  range 

±50% 

Full  range  output  (nominal) 

0  to  +5  VDC 

Scale  factor,  scale  factor  cali- 

30  mV/(°/s),  ±2  %  of 

bration 

value 

Scale  factor  over  temperature 
(dev.  from  22°C) 

<0.06%/°C 

Bias  calibration  (at  22°C) 

+2.5  ±0.045  VDC 

Short  term  bias  stability  (100  s) 

<0.05  % 

Bandwidth 

>50  Hz 

Output  noise  (DC  to  100  Hz) 

<0.05  %/(Hz)1/2 

Operating  temperature 

-40°C  to  +85°C 

Because  the  inertial  measurements  lose  accuracy  over  time,  an  independent  method, 
known  as  global  metrology,  is  used  for  first-order  corrections  to  the  state.  The  global 
metrology  system  works  in  a  manner  similar  to  the  Global  Positioning  System.  Five  bea¬ 
cons  that  transmit  ultrasound  pulses  are  placed  around  the  test  space.  Each  SPHERES  unit 
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has  four  ultrasound  receivers  mounted  on  each  of  six  of  its  faces.  By  measuring  the  time 
of  flight  for  ultrasound  pulses  to  travel  from  the  beacons  to  the  receivers  (and  hence  the 
range),  the  SPHERE  is  able  to  determine  its  position  and  orientation.  The  sequence  goes 
as  follows.  At  a  set  frequency  between  0  and  5  Hz  (usually  2  Hz),  a  "master"  satellite 
requests  a  global  metrology  reading  by  sending  out  a  pulse  from  an  infrared  transmitter. 
The  beacons  detect  this  pulse  and  send  out  their  ultrasound  pulses  in  a  predefined 
sequence.  First  there  is  a  5  millisecond  delay,  then  the  five  beacons  transmit  pulses  one  at 
a  time,  with  20  millisecond  delays  in  between.  Since  the  SPHERES  also  have  infrared 
receivers  that  detect  the  initial  infrared  pulse  by  the  master,  and  they  know  the  timing  of 
the  ultrasound  pulse  transmissions,  they  are  able  to  determine  the  time  of  flight  of  the 
pulses,  and  hence  the  range  between  receiver-beacon  pairs.  They  are  then  able  to  compute 
position  and  attitude  from  this  data,  since  they  know  the  positions  of  the  beacons.  Since 
there  are  uncertainties  in  the  global  measurements,  they  are  combined,  using  Kalman  fil¬ 
tering,  with  the  state  that  is  estimated  from  the  inertial  measurements,  to  yield  the  new 
state.  For  a  detailed  explanation  of  the  algorithms  used  to  determine  position  and  attitude 
from  global  metrology,  see  [HilstadB,  2002]. 

The  intensity  of  the  ultrasonic  transmitters  and  the  sensitivity  of  the  receivers  depend  on 
angle.  As  we  move  away  from  the  direction  in  which  the  transmitter  or  receiver  is  point¬ 
ing,  the  intensity  or  sensitivity  decreases,  as  shown  in  Figure  2.3  for  the  transmitter,  and 
Figure  2.4  for  the  receiver.  Each  ultrasound  emission  is  actually  a  series  of  pulses,  with 
the  initial  ones  being  of  lower  intensities.  Since  the  SPHERES  ultrasound  detection  cir¬ 
cuitry  uses  threshold-based  detection,  off-angle  measurements  yield  time-of-flight  values 
that  are  too  large.  To  negate  this  effect,  the  flight  code  applies  a  correction  based  on  cali¬ 
brations  of  the  transmitters  and  receivers.  The  intensity  of  received  pulses  also  decreases 
with  distance  between  the  transmitter  and  receiver,  so  the  correction  takes  this  into 
account  as  well.  After  the  correction,  individual  distance  measurements  from  transmitter 
to  receiver  are  believed  to  be  accurate  to  ±3  mm  [HilstadA,  2002]. 
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Figure  2.3  Ultrasonic  transmitter  intensity  angle  depen¬ 
dence. 


O' 


Figure  2.4  Ultrasonic  receiver  sensitivity  angle  depen¬ 
dence. 

2.4.5  Avionics 

A  schematic  of  the  SPHERES  avionics  is  provided  in  Figure  2.5.  A  Sundance  SMT375 
board,  featuring  a  Texas  Instruments  TMS320C6701  digital  signal  processor,  runs  the 
SPHERES  flight  code,  including  all  guest  investigator  algorithms.  It  interfaces  with  a 
motherboard  that  provides  electronics  for  communications,  interfacing  with  sensors,  and 
digital  I/O.  The  DSP  communicates  with  the  motherboard  by  way  of  TIM40  standard 
communications  ports  and  a  global  bus.  The  motherboard  has  a  Xilinx  Spartan  II  field- 
programmable  gate  array  (FPGA)  that  provides  support  for  local  sensors  (accelerometers 
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Figure  2.5  SPHERES  avionics.1 

1.  Reproduced  from  SPHERES  CDR  presentation,  Feb.  15,  2002  [Miller,  2002]. 

and  rate  gyros)  and  global  metrology.  The  FPGA  has  12  infrared  receiver  and  24  ultra¬ 
sound  receiver  input  channels,  as  well  as  six  12-bit  A/D  channels.  The  FPGA  calculates 
the  distances  from  ultrasound  beacons  to  receivers  based  on  the  times  that  inputs  are 
received.  The  digital  I/O  on  the  FPGA  consists  of  twelve  outputs  to  control  the  propulsion 
solenoid  valves,  two  general  outputs  (used  to  enable  an  LED  and  reset  a  watchdog  timer), 
as  well  as  two  general  inputs  (used  to  detect  low  battery  signals  and  to  detect  external 
ports). 

2.4.6  Propulsion 

The  SPHERE  controls  its  state  by  firing  its  thrusters.  The  thrust  comes  from  expelling 
C02  gas,  supplied  from  a  liquid  propellant  tank,  through  machined  nozzles.  The  thrusters 
are  actuated  by  electric  solenoids  that  control  micro-valves.  They  operate  in  a  binary  fash¬ 
ion:  they  are  either  on  or  off.  There  are  non-linear  transients  at  the  start  and  end  of  a  pulse, 
when  the  thrust  is  ramping  up  to  or  down  from  its  nominal  value.  A  pressure  regulator 
ensures  that  the  pressure  of  the  gas  reaching  the  nozzles  is  some  constant  value  that  can  be 
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set  between  0  to  50  psig  at  the  start  of  a  test,  providing  for  stable  thrust  throughout  a  test. 
A  single  C02  tank  lasts  for  approximately  10  minutes  of  normal  operations.  Since  the 
thrusters  can  only  operate  at  one  nominal  force  level  (0.2  N  at  50  psig),  they  are  pulse- 
width  modulated  to  achieve  a  greater  range  of  average  forces.  When  a  thruster  that  is  off 
is  commanded  on,  the  electric  solenoids  must  have  voltage  applied  to  them  for  approxi¬ 
mately  6  ms  before  the  valve  will  open.  No  thrust  is  observed  during  this  time.  Therefore, 
the  minimum  commanded  pulse  width  is  set  at  5  ms  in  the  software.  Once  a  valve  begins 
to  open,  it  takes  approximately  1 . 1  ms  for  the  thrust  to  reach  its  nominal  value.  Since  the 
thruster  interrupt  runs  at  1  KHz,  the  pulse  width  resolution  is  1  ms  (ie.  we  can  choose 
when  to  turn  off  the  thrust  to  within  1  ms). 

2.5  Summary 

This  chapter  provided  an  overview  of  the  SPHERES  testbed,  with  particular  attention  paid 
to  those  areas  that  are  of  most  importance  to  the  GFLOPS  SPHERES  Simulator.  First,  the 
basic  control  architectures  that  can  be  tested  with  SPHERES  were  outlined.  Then,  the 
main  features  of  each  of  the  subsystems  of  a  SPHERES  unit  were  described.  This  infor¬ 
mation  is  essential  for  understanding  Chapter  4,  which  will  discuss  how  the  subsystems 
were  modeled  and/or  implemented  in  the  GFLOPS  SPHERES  Simulator. 


Chapter  3 

GFLOPS 


3.1  Introduction 

This  chapter  introduces  the  Generalized  Flight  Operations  Processing  Simulator 
(GFLOPS).  It  begins  by  describing  the  hardware  for  this  real-time  testbed,  then  moves  on 
to  the  software.  The  software  includes  both  the  real-time  operating  system  that  is  used,  as 
well  as  real-time  middleware  that  was  designed  to  facilitate  the  development  of  spacecraft 
flight  software  and  simulations.  This  real-time  middleware  is  known  as  the  GFLOPS 
Rapid  Real-Time  Development  Environment  (GRRDE). 

The  Generalized  FLight  Operations  Processing  Simulator  (GFLOPS)  is  a  testbed  for  the 
simulation  of  distributed  systems,  especially  space  systems.  GFLOPS  was  originally 
developed  as  the  doctoral  thesis  work  of  Enright  [Enright,  2002],  and  is  now  available  for 
more  general  use  in  the  MIT  Space  Systems  Laboratory.  The  usefulness  of  the  GFLOPS 
testbed  has  been  well  demonstrated  with  previous  studies.  The  most  extensive  project 
captured  the  behavior  of  the  United  States  Air  Force’s  TechSat  21  distributed  aperture 
radar  satellite  system.  The  spacecraft  software  in  this  simulation  included  orbit  control, 
attitude  control,  and  radar  processing,  while  the  simulator  software  included  dynamics, 
radar,  sensor,  and  actuator  simulation.  This  project  validated  the  hardware  and  software 
that  make  up  the  GFLOPS  testbed. 
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3.2  Hardware 

The  GFLOPS  hardware  consists  of  eight  PowerCore-6750  single-board  computers  manu¬ 
factured  by  Force  Computers.  The  IBM  PowerPC  750  processors  on  these  boards  run  at 
400  MHz  and  have  access  to  256  MB  of  RAM  each.  They  are  interconnected  by  100 
MBps  Ethernet,  with  a  3Com  Super  Stack  100Base  T  switch.  There  are  up  to  3  support 
personal  computers  (PCs)  that  can  communicate  with  this  embedded  hardware.  This 
allows  for  simulation  monitoring  from  PCs,  sending  of  commands  to  the  embedded  hard¬ 
ware,  and  loading  and  debugging  of  programs.  The  hardware  architecture  is  depicted  in 
Figure  3.1. 


Figure  3.1  GFLOPS  Hardware. 


3.3  OSE  Real-Time  Operating  System 

A  real-time  system  is  one  that  must  complete  activities  and  respond  to  external  events 
while  meeting  timing  requirements.  A  hard  real-time  task  is  one  that  must  be  completed 
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before  its  deadline,  or  severe  consequences  can  arise.  For  example,  an  automatic  pilot 
system  for  an  aircraft  must  update  control  actions  at  a  minimum  rate  in  order  to  maintain 
stability.  Soft  real-time  tasks  do  not  bring  drastic  consequences  if  a  deadline  is  missed, 
but  performance  is  degraded.  For  example,  a  DVD  player  should  update  the  movie  frame 
at  a  specified  rate;"  If  it  misses  a  few  frames,  the  movie  quality  will  suffer,  but  there  will 
not  be  any  greater  consequences.  Many  PC  applications  with  which  we  are  familiar  are 
not  real-time.  While  it  is  desirable  to  produce  a  result  as  quickly  as.  possible,  there  are  no 
ill  effects  if  it  takes  a  bit  longer  than  expected.  An  example  might  be  a  compiler:  we  wish 
the  program  to  be  compiled  quickly,  but  it  does  not  really  matter  if  it  takes  a  few  seconds 
longer  than  expected. 

A  real-time  operating  system  (RTOS)  is  one  that  is  designed  to  host  real-time  applications. 
It  provides  timing  functions,  as  well  as  mechanisms  for  scheduling  processes  and  switch¬ 
ing  between  them.  The  GFLOPS  testbed  employs  the  OSE  RTOS  by  ENEA  OSE  Sys¬ 
tems,  which  is  well  suited  to  distributed  real-time  systems.  OSE  provides  two  types  of 
kernels:  a  real-time  kernel  than  runs  directly  on  embedded  systems,  and  a  soft  kernel  that 
emulates  the  OSE  operating  system  on  a  host  PC.  This  allows  a  system  to  be  distributed 
across  embedded  hardware  and  desktop  PCs.  OSE  comes  with  a  real-time  interface 
known  as  Illuminator  that  facilitates  loading  and  monitoring  of  applications. 

Several  different  types  of  processes  are  available  in  OSE.  It  allows  for  both  static  pro¬ 
cesses,  which  are  created  only  when  an  application  is  loaded  and  exist  until  it  is  killed,  and 
dynamic  processes,  which  can  be  created  or  killed  by  program  code  at  any  time.  Static  or 
dynamic  processes  will  all  be  of  one  of  the  following  types: 

•  Interrupt  processes  are  triggered  when  there  is  a  hardware  interrupt  or  a 
specific  software  event  (such  as  the  sending  of  a  signal  to  the  interrupt  pro¬ 
cess). 

•  Timer  interrupt  processes  mn  at  a  preset  interval. 

•  Prioritized  processes  run  as  an  infinite  loop  that  continues  to  execute  until 
the  process  is  interrupted. 
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•  Background  processes  run  whenever  no  other  processes  have  control  of  the 
processor. 

A  block  is  a  higher-level  object  for  organizing  programs.  It  consists  of  a  number  of  pro¬ 
cesses  and  a  memory  pool  that  they  use.  The  memory  on  a  board  can  be  partitioned  into 
segments,  with  each  segment  providing  the  address  space  for  the  pools  of  one  or  more 
blocks.  These  associations  are  depicted  in  Figure  3.2. 


Figure  3.2  Relationship  between  processes,  blocks,  memory  pools  and  memory  segments. 


In  OSE,  interprocess  communication  occurs  through  message  passing.  These  interprocess 
messages  are  known  as  signals.  A  signal’s  type  is  specified  by  its  signal  number.  In  order 
to  transmit  a  signal,  the  sending  process  must  find  the  process  identifier  of  the  destination 
process,  allocate  memory  for  the  signal,  set  its  signal  number,  and  fill  the  buffer  with  data. 
Each  process  has  an  input  queue  into  which  incoming  signals  are  placed.  The  programmer 
can  choose  to  selectively  receive  incoming  messages  with  particular  signal  numbers.  In 
addition,  processes  can  have  a  redirection  table  that  redirects  some  subset  of  incoming  sig- 
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nals  to  other  processes.  OSE  has  directory  services  that  provide  the  opportunity  to  register 
services,  obtain  their  process  IDs,  and  subscribe  for  notification  of  changes.  In  this  way,  a 
process  that  wishes  to  communicate  with  a  particular  type  of  service  can  find  it  in  the 
directory  if  that  process  has  registered  itself.  The  scenario  is  depicted  in  Figure  3.3. 


Directory  Service 


Figure  3.3  OSE  Name  Service. 


More  information  regarding  the  OSE  RTOS  can  be  obtained  from  the  OSE  User  Manuals 
[ENEA,  1998], 

3.4  GRRDE 

The  GFLOPS  Rapid  Real-Time  Development  Environment  (GRRDE)  extends  the  ser¬ 
vices  of  the  OSE  real-time  operating  system.  One  of  the  most  important  functions  of  this 
real-time  middleware  is  to  enhance  interprocess  communication.  However,  it  also  pro¬ 
motes  program  organization  and  provides  an  object  oriented  interface  to  many  OSE  enti¬ 
ties,  such  as  processes  and  signals.  This  organization  into  objects  simplifies  coding, 
because  we  need  only  to  search  through  the  definition  of  an  object’s  class  to  find  all  the 
related  functions.  Also,  extra  functions  provided  with  the  GRRDE  objects  make  coding 
and  debugging  more  efficient. 
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Other  facilities  that  GRRDE  provides  include  simulation  tools,  timers,  synchronization 
objects,  random  number  generators,  and  atomic  objects.  Atomic  objects  are  guaranteed  to 
be  accessible  for  read/write  operations  by  only  one  process  at  a  time.  A  priority  ceiling 
protocol  is  used  to  avoid  priority  inversion  when  using  atomic  objects  [Enright,  2002], 
Figure  3.4  displays  the  process  for  reading  or  writing  to  an  atomic  object. 


Read/ 

Write 


Another  facility  provided  by  GRRDE  is  time  synchronization.  This  synchronizes  proces¬ 
sor  clocks  on  each  computer.  This  is  necessary  since  there  can  be  drift  between  the  clocks 
on  different  boards  and  a  calculation  on  one  board  could  depend  on  a  time-value  sent  from 
another. 

Functions  for  performing  endian  conversion  are  also  provided.  This  is  necessary  because 
the  embedded  hardware  is  big  endian,  while  the  PCs  used  to  visualize  simulations  are  little 
endian. 

3.4.1  Contracts 

Interprocess  communication  is  extended  with  contracts.  These  are  agreements  between 
two  processes  to  deliver  information  from  one  process  to  the  other.  This  delivery  can  be 
periodic  or  aperiodic.  Periodic  contracts  result  in  the  delivery  of  information  at  a  set  rate 
and  are  best  suited  to  continuously  varying  state  information.  Aperiodic  contracts,  which 
result  in  the  delivery  of  information  only  when  the  associated  variable  changes,  are  useful 
for  infrequently  changing  information. 


Figure  3.4  Read/Write  to  atomic  object. 
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Central  to  the  concept  of  contracts  is  the  notion  of  the  dispatch  function.  A  dispatch  func¬ 
tion  fills  up  a  signal  with  the  relevant  information  and  sends  it  to  the  destination  process. 
Each  contract  is  associated  with  a  specific  dispatch  function  when  the  contract  is  created. 
Contracts  can  be  set  up  by  the  destination  process  ("pull"  contract)  or  the  source  process 
("push"  contract). 

Several  parameters  are  specified  when  creating  a  contract.  We  must  identify  the  desired 
dispatch  function,  the  source  and  sink  processes,  the  period,  the  activation  time  (ie.  there 
can  be  a  delay  before  starting  the  contract)  and  the  contract  duration. 

Two  GRRDE  processes  manage  contract  creation  and  execution.  These  are  the  message 
negotiator  and  message  dispatcher,  respectively.  Contract  requests,  modifications,  and 


Redirection  table 

Figure  3.5  Periodic  contract  setup  and  dispatching. 


service  availability  queries  are  sent  to  the  message  negotiator  of  the  source  block.  The 
message  dispatcher  handles  the  execution  of  contracts  by  calling  the  dispatch  function  at 
the  appropriate  times.  For  periodic  contracts,  a  timer  notifies  the  message  dispatcher  to 
dispatch  the  contract  at  the  correct  times.  The  full  sequence  is  shown  in  Figure  3.5.  Dis¬ 
patching  of  aperiodic  .contracts  is  handled  differently,  as  evidenced  in  Figure  3.6.  For 
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Figure  3.6  Dispatching  of  aperiodic  contracts. 


these,  the  relevant  variables  take  the  form  of  flagged  atomic  objects.  This  special  type  of 
atomic  object  has  a  flag  that  gets  toggled  between  zero  and  one  whenever  it  is  written  to 
(1).  The  object  then  sends  a  signal  to  the  message  dispatcher  to  notify  it  that  one  of  the 
flagged  atomic  objects  has  changed  value  (2).  The  message  dispatcher  does  not  know 
which  object  has  changed,  or  which  dispatch  function  accesses  that  object,  so  it  calls  all 
aperiodic  dispatch  functions  (3).  By  comparing  the  flags  of  the  atomic  objects  that  it  ref¬ 
erences  with  their  values  at  the  last  dispatch,  each  dispatch  function  can  determine 
whether  information  has  changed  and,  if  so,  send  the  information  (4). 

Contracts  simplify  simulation  development  by  separating  the  distribution  of  information 
from  its  creation.  This  allows  for  easier  design,  faster  implementation,  cleaner  code  and 
quicker  debugging. 

3.4.2  GRRDE  Module  Structure 

By  organizing  communication  between  modules  into  a  common  framework,  GRRDE 
allows  for  easier  and  more  efficient  simulation  module  development.  User  processes  con¬ 
tain  the  code  that  accomplishes  the  desired  tasks  set  forth  by  the  developer  when  conceiv- 
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ing  the  module.  They  are  supported  by  a  number  of  GRRDE  processes.  Some  of  these 
processes  are  provided,  while  others  that  must  be  present  have  to  be  coded  by  the  devel¬ 
oper.  The  message  negotiator  and  message  dispatcher,  explained  above,  are  provided 
automatically  and  are  not  modified  by  the  programmer.  Two  processes  that  must  be  coded 
by  the  developer,  but  that  play  specific  roles  within  the  GRRDE  module  framework,  are 
the  block  manager  and  input  arbiter.  The  block  manager  is  the  only  process  that  is  auto¬ 
matically  started  when  a  module  is  run.  It  can  be  used  to  start  the  other  processes,  set  up 
or  reset  contracts,  initialize  global  variables,  and  look  up  other  processes  or  blocks.  The 
input  arbiter  receives  signals  and  either  routes  them  to  the  appropriate  user  process,  or 
extracts  the  data  from  the  signal  and  saves  it  in  the  appropriate  global  variable.  Finally, 
the  block  process,  which  is  automatically  created,  redirects  GRRDE  signals  that  it 
receives  to  GRRDE  processes  within  the  block.  For  example,  new  contract  requests  and 
contract  modification  requests  are  redirected  to  the  message  negotiator.  All  signals  that 
are  not  specified  in  the  table  are  redirected  to  the  input  arbiter. 

3.5  Summary 

This  chapter  provided  a  quick  introduction  to  GFLOPS.  It  began  with  a  description  of  the 
hardware,  then  went  into  the  software  in  greater  detail.  The  main  features  of  OSE,  the 
real-time  operating  system  used  for  GFLOPS,  were  explained.  Then,  the  GFLOPS  Rapid 
Real-Time  Development  Environment  was  addressed,  and  the  ways  in  which  it  simplifies 
interprocess  communication  and  program  organization  were  discussed.  The  topics  dis¬ 
cussed  in  this  chapter  help  to  understand  Chapter  4,  which  details  the  design  of  the  simula¬ 
tion  modules. 
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Chapter  4 


SIMULATOR  ARCHITECTURE  AND 
MODULES 

4.1  Introduction 

This  chapter  describes  the  GFLOPS  SPHERES  Simulator  in  detail.  It  begins  with  some 
insight  into  the  objectives  that  drove  the  design  of  the  simulator.  It  then  discusses  each  of 
the  three  main  simulation  modules  in  turn.  These  are  the  dynamics,  metrology  and 
thruster  simulators.  For  each  of  these,  the  functions  that  the  module  performs  are 
explained  and  the  interactions  with  other  modules  are  outlined.  Next,  the  SPHERES  flight 
software  module  is  covered.  We  see  how  the  SPHERES  interrupts  were  converted  into 
OSE  processes  and  we  learn  of  the  changes  to  SPHERES  code  that  were  necessary  to 
allow  it  to  run  in  the  GFLOPS  environment.  Two  applications  that  allow  the  user  to  mon¬ 
itor  simulations  as  they  proceed  are  dealt  with  next.  These  are  the  3-D  viewer  and  a  pro¬ 
gram  that  simulates  the  user  interface  of  the  SPHERES  laptop.  The  communications 
manager  is  a  module  that  can  be  used  to  filter  the  communications  between  the  SPHERES 
and  the  simulated  laptop,  which  is  necessary  since  there  is  a  limited  bandwidth.  Finally, 
methods  for  investigating  the  resource  usage  of  the  SPHERES  code,  both  in  terms  of  pro¬ 
cessor  utilization  and  memory  usage,  are  discussed. 

4.2  Design  Objectives 

Maximizing  the  usefulness  of  the  GFLOPS  SPHERES  Simulator  required  some  high- 
level  objectives.  First,  as  much  as  possible,  the  simulator  had  to  be  adaptable  to 
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SPHERES  hardware  changes.  The  primary  reason  for  this  was  that  the  final  flight  hard¬ 
ware  was  not  fully  designed  when  the  simulator  was  developed.  Therefore,  the  simulator 
could  not  be  constrained  to  precise  hardware  specifications.  This  adaptability  was 
afforded  by  placing  constants  that  describe  the  hardware  (eg.  force  output  of  a  thruster), 
into  a  single  file,  instead  of  hard-coding  these  constants  into  the  logic  of  the  modules. 
Thus,  as  the  new  specifications  become  available,  they  can  simply  replace  the  old  ones  in 
the  constants  file. 

The  simulator  also  had  to  remain  adaptable  to  changes  of  the  SPHERES  software  since  the 
SPHERES  flight  code  will  be  modified  frequently,  even  in  between  tests  onboard  the 
International  Space  Station.  In  order  to  achieve  this  objective,  changes  needed  to  adapt 
pre-existing  SPHERES  code  to  the  GFLOPS  testbed  (eg.  for  communications  between 
satellites)  had  to  be  implemented  in  a  way  that  would  be  transparent  at  the  level  of  the 
guest  scientist  control  code.  That  is,  we  wanted  to  have  to  replace  code  with  OSE  function 
calls  only  in  the  lowest-level  SPHERES  functions.  Then,  when  the  Standard  Control 
Interface  is  used,  the  same  guest  scientist  algorithm  can  be  compiled  successfully  for  the 
GSS  or  for  the  actual  SPHERES  hardware.  The  guest  scientist  need  not  be  aware  of  the 
contents  of  the  low-level  functions. 

Another  design  objective  was  to  make  sure  that  the  simulator  was  capable  of  handling  any 
control  architecture  (eg.  leader-follower,  master/slave).  The  simulator  modules  (the 
thruster,  dynamics  and  metrology  simulators)  were  designed  in  a  very  generic  way  and  do 
not  limit  this  flexibility.  The  main  requirement  for  achieving  different  formation  flying 
architectures  was  to  allow  for  communications  between  the  satellites  themselves,  and 
between  the  satellites  and  the  simulated  laptop. 

Modularity  was  also  considered  a  very  desirable  trait.  Separating  functions  such  as 
thruster,  dynamics  and  metrology  simulation  into  different  modules  increased  the  likeli¬ 
hood  that  changes  or  improvements  to  the  simulator  would  be  constrained  to  a  small  sec¬ 
tion  of  code.  For  example,  if  we  wanted  to  improve  the  modelling  of  thrusters,  then  we 
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would  only  need  to  modify  the  thruster  simulator.  This  increased  the  maintainability  of 
the  simulator.  Thorough  commenting  and  documentation  was  also  carried  out  in  order  to 
facilitate  maintenance  by  others. 

Other  objectives  included  closely  maintaining  the  timing  characteristics  of  the  flight  code 
and  making  it  possible  to  investigate  flight  code  processor  utilization.  In  addition,  we 
wished  to  utilize  the  GRRDE  toolset  to  simplify  and  speed  up  development  of  the  simula¬ 
tor. 

Figure  4. 1  shows  the  general  architecture  of  the  GFLOPS  SPHERES  Simulator.  Details 
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Figure  4.1  Simulation  Architecture. 


about  each  of  the  elements  of  the  simulator  are  given  in  the  following  sections. 


4.3  Dynamics  Simulator 

The  dynamics  simulator’s  primary  function  is  to  propagates  the  state  of  the  SPHERES.  It 
receives  forces  and  torques  from  the  thruster  simulator  and  provides  state  information  to 
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the  metrology  simulator.  It  can  handle  collisions  between  two  SPHERES,  or  between  a 
SPHERE  and  a  wall.  It  can  also  accomodate  docking  between  two  SPHERES,  where  the 
units  stick  together  after  the  dock.  In  addition,  the  user  can  choose  to  log  a  history  of  the 
forces  and  torques  acting  on  a  SPHERE,  or  he  can  apply  a  disturbance  force  or  torque  to 
the  SPHERE.  These  capabilities  will  now  be  described  in  more  detail. 

4.3.1  State  Propagation 

The  dynamics  simulator  propagates  the  states  of  all  satellites.  Thirteen  variables  are  prop¬ 
agated  for  each  SPHERE:  three  for  position,  three  for  velocity,  four  that  make  up  the 
quaternion  that  describes  the  satellite’s  orientation  in  the  global  frame,  and  three  for  rota¬ 
tional  velocity  about  each  of  the  satellites  body  axes.  The  SPHERE’S  acceleration  and 
angular  acceleration  are  also  contained  in  six  other  variables;  these  are  simply  updated 
when  thrusters  are  turned  on  or  off. 

To  solve  the  equations  of  dynamics  of  the  SPHERE,  a  public  domain  function  for  the 
numerical  solution  of  systems  of  first  order  ordinary  differential  equations  with  initial  con¬ 
ditions  is  used.  Named  Dverk,  it  employs  a  Runge-Kutta  algorithm  based  on  Vemer’s  fifth 
and  sixth  order  pair  of  formulae  and  attempts  to  keep  the  global  error  proportional  to  a 
specified  tolerance.  To  tailor  this  solver  to  the  problem  at  hand,  the  relevant  first  order 
equations  had  to  be  specified.  The  equations  for  position  and  velocity  are  as  follows: 

?  =  v  (4.1) 

F 

v  =  -  (4.2) 

m 

where  m  is  the  mass  of  the  SPHERES  unit  and  F  is  the  force  exerted  on  it.  Inside  the 
function  that  contains  the  first  order  equations,  and  which  is  called  repeatedly  by  Dverk 
with  different  values  for  the  time  argument,  the  force  on  the  SPHERE  is  converted  from 
the  body  frame  to  the  global  frame.  This  ensures  that  the  global  frame  force  values  are 
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kept  accurate,  which  is  important  because  if  the  SPHERE  is  spinning,  then  the  force  vec¬ 
tor,  while  constant  in  the  body  frame,  is  rotating  in  the  global  frame. 


The  rates  of  change  of  the  quaternion  elements  are: 
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The  rate  of  change  of  angular  velocity  about  the  body  axes  are: 


co  =  (7)  ](T-cox(/co)) 


(4.5) 


where  co  is  the  angular  velocity  vector,  I  is  the  inertia  matrix  of  the  satellite  and  T  rep¬ 
resents  the  torques  about  (he  body  axes.  The  forces  and  torques  acting  on  the  SPHERE  are 
sent  to  the  dynamics  simulator  from  the  thruster  simulator.  They  will  be  further  discussed 
in  Section  4.5. 

The  SPHERE’S  state  must  be  re-propagated  each  time  the  force  or  torque  acting  on  it 
changes..  If  thruster  states  were  constant  for  long  periods  of  time  (eg.  a  second),  the  most 
computationally  efficient  method  of  updating  the  state  would  be  to  propagate  the  dynam¬ 
ics  far  into  the  future,  and  use  an  interpolation  function  to  obtain  intermediate  values. 
However,  since  the  SPHERE’S  control  frequencyds  10  Hz  and  different  thrusters  turn  off 
at  different  times,  we  would  be  repropagating  frequently  anyway,  so  there  would  not  be 
much  point  in  interpolating  between  propagations  (it  would  only  complicate  the  code). 
Therefore,  we  do  not  use  interpolation,  and  we  propagate  the  state  up  to  the  current  time 
whenever  the  thruster  states  change.  In  addition,  the  state  is  automatically  propgagated  if 
the  thruster  states  haven’t  changed  in  the  last  5  ms.  Given  the  relatively  slow  motion  of  a 
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SPHERE,  this  update  rate  is  sufficient  to  achieve  accurate  metrology  simulation.  Thus, 
the  state  is  always  between  0  and  5  ms  old. 

4.3.2  Dynamics  Simulator  Features 

Arbitrary  Offset  of  SPHERE  Center  of  Mass 

A  feature  of  the  dynamics  simulator  is  that  an  arbitrary  offset  of  the  SPHERE’S  center  of 
mass  from  its  geometric  center  can  be  specified.  We  should  note  that  it  is  the  position  and 
velocity  of  the  center  of  mass  that  get  propagated.  Thus,  since  the  SPHERE  requires 
knowledge  of  the  position  and  velocity  of  its  geometric  center,  conversions  are  made 
before  sending  values  to  the  metrology  simulator,  as  follows: 

f  =  fcm  +  r  <4-6) 

v  =  vcm  +  (0  X  r'  +  v'  =  vcm  tax?  (4-7) 

a  =  acm  +  ©  x  r'  +  to  x  (to  x  r')  +  2co  x  v'  +  a'  =  acm  +  co  x  f  +  (D  x  (go  x  r')  (4-8) 

where  the  subscript  cm  refers  to  the  state  of  the  center  of  mass  of  the  SPHERE,  and  r\  v' 
and  a'  refer  to  the  relative  position,  velocity  and  acceleration  of  the  SPHERE’S  geometric 
center  with  respect  to  its  center  of  mass,  in  the  body  frame  ( v'  and  ci'  are  zero). 

Collisions 

Collisions  are  checked  for  every  100  ms.  By  approximating  their  shape  as  spherical,  we 
can  test  for  collisions  between  two  units  by  checking  whether  the  difference  in  their  posi¬ 
tions  is  less  than  two  radii  of  a  SPHERE.  When  a  collision  occurs,  the  SPHERES  veloci¬ 
ties  are  changed  to  reflect  this.  The  magnitude  of  the  component  of  the  relative  velocity  of 
approach  that  is  parallel  to  the  surface  normal  at  the  point  of  collision  is  multiplied  by  the 
coefficient  of  restitution  for  two  SPHERES,  es,  to  obtain  the  magnitude  of  the  relative 
velocity  of  separation: 
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(Vi  f-n)-(y2rn) 

(vir«)-(v2,-«) 


(4.9) 


Note  that  es  is  chosen  arbitrarily.  Here,  n  is  a  normal  at  the  collision  surface,  and  the  sub¬ 
scripts  i  and / denote  conditions  just  prior  to  and  just  after  the  collision.  The  normal  is  an 
approximation  derived  from  the  spherical  approximation.  Since  the  satellites  have  the 
same  mass,  their  changes  in  velocity  will  be  equal  in  magnitude  and  opposite  in  direction 
in  order  to  conserve  momentum.  We  do  not  capture  rotational  effects  during  collisions  (ie. 
angular  momentum  is  not  conserved).  In  addition  to  SPHERE-SPHERE  collisions,  a 
check  can  be  made  to  see  whether  the  satellite  has  collided  with  a  wall  surrounding  the  test 
space.  If  a  collision  has  occurred,  the  component  of  the  unit’s  velocity  that  is  perpendicu¬ 
lar  to  the  wall  is  multiplied  by  -evv,  where  ew  is  the  coefficient  of  restitution  for  a  collision 
between  a  SPHERE  and  a  wall.  This  simulates  a  bounce  off  of  the  wall  with  some  energy 
loss. 


Docking 

If  the  user  wishes  to  run  an  algorithm  that  tests  docking  between  two  SPHERES,  the 
dynamics  simulator  can  be  compiled  to  support  docking.  The  user  sets  a  vector  that  spec¬ 
ifies  the  direction  in  body  coordinates  that  points  from  the  center  of  the  SPHERE  to  the 
middle  of  the  docking  port  or  panel  (currently  assumed  to  be  the  same  vector  for  all 
SPHERES).  When  a  collision  occurs  between  two  SPHERES,  the  dynamics  simulator 
checks  to  see  if  the  docking  ports  for  the  two  SPHERES  have  come  into  contact.  This  is 
done  by  checking  the  orientation  of  the  two  units  and  the  proximity  of  their  docking  ports. 
For  them  to  have  docked,  the  vectors  pointing  to  their  docking  ports  must  be  pointing  in 
opposite  directions  and  their  docking  ports  must  be  in  close  proximity.  These  relations  are 
expressed  in  the  following  inequalities, 

A  A 

acos((J?1a)  •  (R2a))  >  n  -  <E> 


(4.10) 
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|(f1  +  pJR1a)-(r2  +  pJf?2oc)|<C 


(4.11) 


where  R(  is  the  rotation  from  SPHERE  V s  body  frame  coordinates  to  global  frame  coordi¬ 
nates,  a  is  the  unit  vector  pointing  towards  the  docking  port  in  body  coordinates,  O  is  an 
angle  representing  the  maximum  angular  offset  of  the  docking  ports,  ri  is  the  position  of 
SPHERE  i,  p  is  the  radius  of  a  SPHERE,  and  £  is  the  maximum  linear  port  offset. 


When  the  above  constraints  are  met,  the  SPHERES  are  considered  to  have  docked.  Since 
it  is  assumed  that  the  docking  port  will  consist  of  velcro,  once  two  SPHERES  have  docked 
they  remain  together  as  a  rigid  body.  The  center  of  mass  of  the  composite  object,  rccm  ,  is 
the  average  of  the  centers  of  mass  of  the  two  SPHERES,  while  conservation  of  momentum 
gives  the  velocity  of  the  combined  center  of  mass,  vccm  : 


T  — 
ccm 


^ cm  1  "1"  ^cm2 


(4.12) 


_  Vcm\  Vcm2 
vccm  ~  O 


(4.13) 


Angular  momentum  must  also  be  conserved  during  the  docking.  This  is  done  by  consider¬ 
ing  the  angular  momentum  about  the  location  of  the  composite  center  of  mass.  Just  prior 
to  the  docking,  this  will  be  equal  to  the  following  (the  angular  momentum  resulting  from 
the  rotation  of  the  units  is  ignored  before  the  docking): 

Hccm(i)  =  rcm  1  X  m ~Vcm 1  +  'rcm2  X  m^cm2  (4‘ 14) 

where  now  fcmi  is  the  position  of  the  SPHERE  i’s  center  of  mass  with  respect  to  the 
composite  center  of  mass. 


After  the  docking,  the  angular  momentum  will  be  due  to  the  rotation  of  the  composite 
object  about  its  center  of  mass: 
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Hccm(j)  I c ®  Hccm(i)  (4.15) 

where  Ic  is  the  inertia  matrix  of  the  composite  object.  The  angular  rates  of  the  composite 
object  can  be  arrived  at  by  multiplying  both  sides  of  equation  4.15  by  IJ1.  Since  the  rela¬ 
tive  orientations  of  the  docked  SPHERES  cannot  be  known  a  priori,  Ic  must  be  determined 
at  the  time  of  the  docking  by  combining  the  moments  of  inertia  of  each  of  the  SPHERES. 
First,  using  the  parallel  axis  theorem,  each  of  their  moments  are  determined  about  the 
composite  object’s  center  of  mass,  shown  here  for  SPHERE  i: 


T  i  =  I.  + 


cmi  cmi 


■  r  -r  T  .) 

cmi  cmi ' 


(4.16) 


Next,  they  can  be  combined  together  after  rotating  them  into  the  composite  object’s  body 
frame: 


Ic  =  RxIxRi  +  RJjRi  (417) 

Once  docking  has  occured,  the  simulator  propagates  the  position,  velocity,  orientation,  and 
angular  velocity  of  the  composite  object.  Since  the  positions  of  the  docked  SPHERES 
with  respect  to  the  combined  center  of  mass  and  their  orientations  with  respect  to  that  of 
the  composite  object  are  known,  the  states  of  the  SPHERES  themselves  can  be  calculated 
with  respect  to  the  global  frame.  For  position,  velocity  and  acceleration,  modified  ver¬ 
sions  of  equations  4.6,  4.7,  and  4.8  are  used,  with  the  center  of  mass  quantities  replaced 
with  combined  center  of  mass  values: 

r  =  r  +  V  (4-18) 

ccm  v 

V  =  +  +  =  Vccm  +  axr'  (4.19) 

a  =  accm  +  to  x  r'  +  co  x  (co  x  r’)  +  2co  xv'  +  a1  =  accm  +  co  x  r'  +  m  x  (co  x  r')  (4-20) 
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where  r'  is  now  the  original  offset  of  the  SPHERE’S  geometric  center  from  its  center  of 
mass  plus  the  offset  of  the  SPHERE’S  center  of  mass  from  the  combined  center  of  mass. 
Because  the  docked  SPHERES  form  a  rigid  body,  the  angular  rate  and  acceleration  can  be 
arrived  at  by  simply  rotating  those  of  the  composite  object  into  the  SPHERE’S  body 
frame. 

Immediately  after  executing  the  dock,  the  dynamics  simulator  will  send  a  signal  to  the 
thruster  simulator  to  notify  it  that  docking  has  taken  place.  This  is  necessary  because  the 
thruster  simulator  must  recalculate  the  positions  of  thrusters  with  respect  to  the  new  center 
of  mass,  the  directions  in  which  thrusters  produce  force  in  the  new  body  frame,  and  the 
torque  produced  by  a  unit  force  from  a  thruster.  During  the  time  between  docking  and 
acknowledgment  from  the  thruster  simulator  that  these  new  values  have  been  calculated, 
the  dynamics  simulator  ignores  forces  and  torques  sent  from  the  thruster  simulator.  This  is 
to  avoid  having  the  docked  SPHERES  fly  apart. 

Force  and  Torque  Recording 

The  dynamics  simulator  is  capable  of  sending  signals  containing  a  log  of  the  commanded 
forces  and  torques  acting  on  a  SPHERE  to  other  applications.  Forces  are  specified  in  the 
global  frame,  while  the  torques  are  expressed  in  the  body  frame.  Each  time  a  force  or 
torque  is  received  from  the  thruster  simulator,  the  data  are  saved  and  time-stamped.  To 
avoid  excessive  signal  traffic,  data  are  accumulated  until  they  occupy  the  maximum  OSE 
signal  size.  Then  the  signal  is  sent  to  the  requesting  application. 

User-Applied  Disturbances 

The  dynamics  simulator  can  apply  arbitrary  force  and  torque  disturbances  to  the 
SPHERES.  The  duration  of  the  disturbance  is  specified  in  milliseconds.  This  time  will  be 
rounded  up  to  the  next  integral  number  of  integration  periods.  Thus,  the  applied  distur¬ 
bance  may  persist  for  slightly  longer  than  requested.  The  disturbance  force  and  torque, 
their  duration,  and  the  ID  of  the  affected  SPHERE  are  sent  to  the  dynamics  simulator  in  a 
signal.  Note  that  the  magnitude  and  direction  of  the  force  or  torque  is  constant  for  the 
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entire  duration  of  the  disturbance.  More  complex  disturbances  would  need  to  be  coded 
into  the  state  propagation  routines  directly. 

4.3.3  External  Signals 

The  dynamics  simulator  receives  several  external  signals,  mostly  commands  from  the  user 
or  other  modules: 

•  DYN_SIM_FORCE_TORQUE_INPUT  is  sent  by  the  thruster  simulator 
and  contains  the  updated  torques  and  forces  acting  on  a  SPHERE  and  that 
SPHERE’S  ID. 

•  DYN_SIM_SET_INITIAL_STATE  contains  the  thirteen  variables  that 
make  up  the  initial  state  of  the  SPHERE  and  is  sent  to  the  dynamics  simula¬ 
tor  when  a  new  satellite  is  added  to  the  simulation. 

•  START_SIMULATION  starts  the  simulation  by  informing  the  dynamics 
simulator  to  start  propagating  the  satellites’  states. 

•  DYN_SIM_DISTURB_SPHERE  causes  a  SPHERE  to  experience  a  distur¬ 
bance  force  or  torque  for  a  specified  length  of  time. 

•  DYN_SIM_REQ_THRUST_STATS  is  sent  by  applications  that  wish  to 
receive  records  of  the  force  and  torque  history  for  all  active  SPHERES. 

•  DYN_SIM_STOP_THRUST_STATS  stops  the  sending  of  force/torque 
logs. 

•  DYN_SIM_RESET_SIM  resets  the  states  of  all  SPHERES  to  their  default 
values  and  removes  them  from  the  simulation. 

•  D YN_SIM_DOCKIN G_ACKN O WLEDGE  is  received  from  the  thruster 
simulator  and  signifies  that  the  dynamics  simulator  no  longer  needs  to  ignore 
force/torque  signals  sent  for  recently  docked  SPHERES. 

Three  dispatch  functions  are  provided  by  the  dynamics  simulator: 

•  dyn_sim_full_state  sends  a  signal  containing  the  values  of  the  thirteen  state 
variables  for  the  requested  satellite. 

•  dyn_sim_extended_state  sends  the  same  information  as  dyn_sim_full_state 
along  with  the  six  acceleration  variables. 

•  dyn_sim_all_sats_state  is  similar  to  dyn_sim_extended_state,  but  contains 
the  data  for  all  satellites  at  once. 

Each  of  these  functions  also  send  the  time  that  has  elapsed  since  the  start  of  the  simulation. 
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4.4  Metrology  Simulator 

4.4.1  Metrology  Simulation 

The  metrology  simulator  enables  the  SPHERES  to  receive  Inertial  Measurement  Unit 
(IMU)  and  global  metrology  readings.  IMU  readings  contain  the  values  from  the  three 
single-axis  rate  gyros  and  the  three-axis  accelerometer.  As  soon  as  a  SPHERE  receives  an 
IMU  reading,  it  asks  for  a  new  one.  To  ensure  that  the  time  between  IMU  readings  is  not 
too  small,  the  metrology  simulator  waits  for  18  ms  before  fulfilling  an  IMU  request  (it  is 
not  known  what  the  actual  time  between  received  IMU  measurements  is  for  the  SPHERES 
hardware).  The  IMU  readings  sent  to  the  SPHERE  are  in  units  of  millivolts. 

The  metrology  simulator  models  the  non-ideal  characteristics  of  the  accelerometer  and 
gyros.  These  parameters  were  specified  in  Table  2.3  and  Table  2.4  respectively.  If  the 
acceleration  or  angular  rate  is  outside  of  the  input  range,  the  measurement  saturates  at  the 
extremity  of  the  range.  The  accelerometer  resolution  is  also  modeled,  so  that  the  output  of 
the  accelerometer  can  only  be  a  multiple  of  5  (ig. 

Noise  is  added  according  to  the  values  given  in  the  tables,  with  the  assumption  that  no 
noise  exists  outside  of  the  bandwidths  listed.  The  noise  entries  in  the  tables  are  given  as 
square  roots  of  power  spectral  densities.  These  can  be  used  to  determine  the  noise  mea¬ 
sured  in  bandwidth  B  as  follows  [Fish,  1994]: 

l 

eRMS  =  e-®  (4-21) 

where  £  is  the  root  of  the  power  spectral  density  in  bandwidth  B.  The  root  mean  square 
value  of  the  noise  is  eRMS.  Noise  is  added  to  the  signals  using  a  GRRDE  normal  random 
number  generator  with  a  mean  of  zero  and  a  stardard  deviation  of  eRMS.  The  resulting  val¬ 
ues,  in  rad/s  or  m/s2,  are  converted  to  millivolts  according  to  the  following  equation: 

V  =  (S  +  e){ScaleF actor)  +  Bias 


(4.22) 
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where  V  is  the  resulting  voltage,  S  is  the  value  of  acceleration  or  angular  rate  received 
from  the  dynamics  simulator,  e  is  the  noise  added  to  the  signal,  ScaleFactor  is  the  scale 
factor  of  the  device  in  millivolts/unit,  and  Bias  is  the  bias  of  the  device  in  millivolts. 

Currently,  the  metrology  simulator  is  compliant  with  the  global  metrology  system  for  the 
prototype  SPHERES.  The  metrology  simulator  starts  a  new  global  metrology  transmit 
cycle  at  a  set  period,  nominally  every  153  ms.  In  contrast,  with  the  flight  SPHERES,  the 
"master"  SPHERE  will  create  an  infrared  flash  to  request  a  new  global  metrology  cycle. 
With  the  real  prototype  SPHERES,  the  CPU  would  request  a  global  metrology  reading  by 
notifying  the  metrology  board  (the  Tattletale  8),  which  would  return  the  data  once  it  has 
been  acquired.  In  the  simulation,  instead  of  communicating  with  the  Tattletale,  the 
SPHERE  requests  global  metrology  data  from  the  metrology  simulator.  At  the  start  of 
each  cycle,  the  metrology  simulator  checks  which  SPHERES  units  have  requested  global 
metrology  data.  After  the  initial  5  ms  delay  (see  Section  2.4.4),  the  distances  from  each 
transmitter  to  each  receiver  on  the  SPHERE  are  computed  and  saved.  This  is  done  for  a 
different  transmitter  every  20  ms.  After  all  beacons  have  been  considered,  the  completed 
measurement  is  sent  to  the  SPHERE.  These  delays  make  the  simulated  measurements  and 
timing  representative  of  the  actual  system. 

The  distance  measurements  must  be  modified  to  account  for  the  actual  behavior  of  the 
hardware.  As  explained  in  Section  2.4.4,  the  times-of-flight  measured  by  the  global 
metrology  system  depend  on  the  distance  and  relative  orientation  between  transmitter  and 
receiver.  A  modified  version  of  the  function  correct_gGlobal  from  the  SPHERES 
flight  software  is  called  from  the  metrology  simulator  to  apply  these  corrections.  The 
function  is  the  same  as  in  the  flight  software,  except  that  the  opposite  corrections  are 
applied  to  simulate  the  physical  effects  that  are  corrected  in  the  flight  software.  With  this 
reverse  correction  applied  by  the  metrology  simulator,  the  distances  are  expected  to  be 
close  to  those  that  would  be  measured  in  the  real  system.  Of  course,  these  values  can  only 
be  as  accurate  as  the  calibration  that  was  used  to  create  the  correct_gGlobal  func¬ 
tion.  However,  even  with  a  perfect  calibration,  the  distances  that  the  SPHERE  calculates 
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after  calling  correct_gGlobal  would  not  be  perfect.  In  order  to  perform  the  correc¬ 
tion,  the  SPHERE  needs  to  estimate  the  transmitter  angle  (0t  in  Figure  4.2)  and  the 


Figure  4.2  Receiver  and  transmitter  angle. 


receiver  angle,  0P  for  each  beacon-receiver  pair.  The  SPHERE  estimates  these  angles 
using  the  uncorrected  distance  measurements,  so  there  will  always  be  some  error  in  the 
angles  that  are  arrived  at,  and  hence  in  the  distance  correction. 

4.4.2  External  Signals 

The  metrology  simulator  receives  several  external  signals: 

•  DYN_SIM_ALL_SATS_STATE  contains  the  state  updates  from  the 
dynamics  simulator.  These  are  sent  every  millisecond.  Because  the  dynam¬ 
ics  simulator  can  take  as  long  as  5  ms  to  update  the  state  for  a  satellite,  con¬ 
secutive  signals  often  contain  duplicate  information.  This  is  not  a  problem. 

•  SPH_SENSOR_SIM_GM_REQUEST  contains  a  global  metrology 
request  form  a  SPHERE. 

•  SPH_SENSOR_SIM_IMU_REQUEST  contains  an  IMU  request  from  a 
SPHERE. 

4.5  Thruster  Simulator 

The  thruster  simulator  module  is  sent  THRUST_SIG  signals  from  the  SPHERES  in  the 
simulation  every  time  they  change  the  combination  of  thrusters  that  are  activated.  The 
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THRUST_SIG  signal  contains  a  bit-packed  integer  that  indicates  whether  each  thruster  is 
on  or  off.  The  simulator  models  the  force  profile  of  a  thruster  as  shown  in  Figure  4.3. 


Force 


Simulated  Thrust  Profile 


OFF 


Figure  4.3  Actual  and  simulated  thrust  profiles. 


A  thruster  takes  6  ms  to  open.  This  is  due  to  the  fact  that  voltage  must  be  applied  for  this 
minimum  amount  of  time  before  the  the  valve  will  begin  opening.  Once  the  valve  starts 
to  open,  it  takes  approximately  1.1  ms1  for  the  force  to  reach  its  nominal  value  of  0.2  N. 
While  this  transient  behavior  is  depicted  in  the  left  side  of  the  figure  as  a  linear  increase  in 
thrust,  it  is  in  fact  non-linear.  There  is  also  some  transient  behavior  as  the  valve  closes.  To 
simplify  the  representation  of  the  thrust  profile,  the  simulated  profile  ignores  the  tran¬ 
sients.  After  the  6  ms  delay,  the  force  takes  its  nominal  value,  and  it  goes  immediately  to 
zero  when  a  thruster  is  commanded  off.  For  the  linear  profile  in  the  left  side  of  the  figure, 
if  the  ramp  up  and  ramp  down  time  are  equal,  then  the  right  profile  will  have  the  same  area 
under  the  curve,  or  same  impulse.  The  thruster  simulator  keeps  a  record  of  the  last  com¬ 
manded  thruster  states  for  each  satellite,  the  time  of  these  commands,  and  the  current 
thruster  states.  During  the  6  ms  opening  delay,  the  current  and  commanded  states  will  dif¬ 
fer. 

The  main  thruster  simulator  process  runs  every  millisecond  and  performs  a  variety  of 
tasks.  First,  it  checks  for  unprocessed  THRUST_SIG  signals  waiting  in  its  signal  queue. 
It  processes  them  all  and  updates  the  record  of  current  thruster  states.  Second,  the  simula- 

1 .  This  value  of  1 . 1  ms  was  obtained  by  Simon  Nolet,  SPHERES  team  member  and  MIT  SSL  graduate  stu¬ 
dent,  in  email  correspondence  with  hardware  manufacturers. 
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tor  checks  whether  the  valve  opening  delay  has  just  expired  for  any  thrusters  and,  if  so, 
records  the  change.  If  the  thruster  states  have  changed  for  a  SPHERE,  either  from  a  new 
command  or  from  a  delay  expiring,  new  force  and  torque  values  are  sent  to  the  dynamics 
simulator.  Normally  distributed  noise  can  be  added  to  the  output  of  a  thruster.  The  forces 
about  the  center  of  mass  in  the  body  frame  are  computed  as  follows: 

N 

F=^(Thi)di  (4.23) 

i  =  1 

In  this  equation,  N  is  the  number  of  thrusters  per  SPHERE,  Tht  is  the  current  thrust  output 
of  thruster  i,  and  d,  is  a  unit  thrust  in  the  body  frame. 

Since  the  thruster  positions  and  the  thrust  vectors  are  known,  we  can  compute  the  torques 
about  the  body  axes  that  arise  from  a  unit  force  from  each  thruster: 

Ti  =  Rixdi  (4.24) 

Here,  7)  is  the  torque  that  results  when  thruster  i  produces  a  unit  force,  while  Rj  is  the 
position  of  thruster  i  with  respect  to  the  center  of  mass  of  the  SPHERE.  With  vV  thrusters, 
the  total  torque  is  given  by: 


N 

T=  ^(ThJTi  (4.25) 

i  =  1 

When  a  docking  between  SPHERES  is  sensed  by  the  dynamics  simulator,  it  sends  a  signal 
to  notify  the  thruster  simulator.  The  signal  contains  the  IDs  of  the  affected  units,  the  posi¬ 
tions  of  their  geometric  centers  with  respect  to  the  new  center  of  mass,  and  the  quaternions 
representing  their  orientations  in  the  new  body  frame.  The  thruster  simulator  recalculates 
equations  4.23  and  4.24  so  that  thruster  firings  for  each  of  the  docked  SPHERES  are  now 
converted  into  forces  and  torques  specified  in  the  new  body  frame.  And  when  sending  the 
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forces  and  torques  of  one  of  the  docked  SPHERES  to  the  dynamics  simulator,  the  thruster 
simulator  adds  the  values  that  are  due  to  the  thrusters  from  both  docked  SPHERES. 

4.6  SPHERE  Module 

The  SPHERE  module  encapsulates  the  SPHERES  flight  code.  The  primary  goal  in 
designing  this  module  was  to  minimize  differences  between  simulation  code  and  actual 
flight  code.  However,  the  SPHERE  module  is  running  on  different  hardware  and  a  differ¬ 
ent  operating  system  than  in  the  actual  system,  so  it  was  impossible  to  make  the  code  iden¬ 
tical.  Low-level  calls  that  access  hardware  could  not  be  left  unchanged  in  the  simulation. 
In  particular,  instead  of  using  wireless  communications  to  communicate  with  other  units 
or  the  laptop  application,  the  SPHERE  module  must  communicate  using  OSE  signals. 
However,  the  goal  of  the  GSS  was  not  to  test  the  communications  hardware.  It  was  meant 
to  verify  the  guest  investigator  formation  flying  algorithms.  These  will  almost  certainly 
contain  satellite-to-satellite  (STS)  and  satellite-to-laptop  (STL)  communications,  but  as 
long  as  the  information  arrives  at  the  destination,  we  need  not  be  concerned  with  the  exact 
transmission  method.  Furthermore,  through  careful  design  of  the  SPHERE  module,  we 
ensured  that  the  timing  characteristics  of  communications  and  other  functions  are  similar 
to  those  in  the  real  system. 

4.6.1  SPHERE  Module  Processes 

As  explained  in  Section  2.4.2,  the  SPHERES  flight  code  is  partitioned  into  four  principal 
sections.  There  are  two  timer-interrupts  (the  thruster  actuator  and  controller),  an  event- 
driven  interrupt  (for  communications)  and  some  background  processing.  Correspond¬ 
ingly,  there  are  four  main  elements  of  the  SPHERE  module.  At  first  glance,  the  logical 
choice  would  have  been  to  replace  the  thruster  and  controller  sections  with  OSE  timer- 
interrupt  processes,  and  the  communications  section  with  an  OSE  software  interrupt  pro¬ 
cess  that  gets  awakened  when  it  receives  a  signal.  However,  interrupt  processes  in  OSE 
cannot  send  or  receive  signals  from  processes  that  are  not  part  of  the  same  block.  Since 
the  thruster  actuator  must  send  thrust  signals  to  the  thruster  simulator,  and  the  communica- 
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tions  interrupt  must  communicate  with  several  other  modules,  these  could  not  be  coded  as 
OSE  timer-interrupts.  Furthermore,  interrupts  have  higher  priority  than  any  other  process 
in  OSE.  Thus,  the  controller,  which  must  be  at  a  lower  priority  than  the  other  two,  could 
not  exist  as  a  timer-interrupt  either. 

Thruster  Actuator 

Instead  of  an  interrupt-based  solution,  the  thruster  actuator  was  implemented  as  a  dispatch 
function  named  "SPHERE_send_thrusts".  The  dispatch  function  increments  counters  that 
keep  track  of  time,  propellant  usage  and  battery  usage,  asks  for  a  new  global  metrology 
reading  every  second,  and  checks  whether  each  thruster  should  be  on  or  off.  The  code  for 
the  dispatch  function  is  taken  straight  from  the  original  code  for  the  propulsion  interrupt. 
The  only  substantial  difference  is  that,  instead  of  writing  the  thruster  commands  to  a  hard¬ 
ware  port,  it  writes  them  to  a  signal  that  gets  sent  to  the  thruster  simulator.  A  push  con¬ 
tract  between  the  thruster  actuator  and  the  thruster  simulator  ensures  that  thrust  values  can 
be  updated  every  millisecond,  just  as  in  the  flight  code.  However,  the  simulator  is  only 
notified  when  the  thruster  states  change.  If  the  thruster  settings  remain  constant,  we  do 
not  send  updates  to  the  simulator. 

Communications  Process 

The  communications  interrupt  routine  inputs  received  communications  data  into  global 
arrays  so  that  the  data  can  be  accessed  by  other  processes.  It  was  coded  as  a  prioritized 
process  that  is  enabled  whenever  it  receives  a  signal,  just  as  the  actual  communications 
interrupt  wakes  up  whenever  incoming  data  is  available.  Minor  adaptations  were  made  to 
the  code.  For  example,  instead  of  reading  from  a  hardware  device,  communications  mes¬ 
sages  are  received  via  OSE  signals.  Nonetheless,  the  data  gets  put  in  the  same  arrays  and 
the  timing  characteristics  are  comparable. 
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Controller 

The  controller  process  is  extremely  simple.  It  starts  a  timer  that  sends  stimulus  signals  to 
the  process  at  50  Hz.  Each  time  this  wrapper  process  receives  one  of  these  signals,  it  exe¬ 
cutes  the  flight  version  of  the  controller  code. 

Background  Processing 

The  background  processing  from  the  flight  code  was  put  into  an  OSE  background  process. 
This  code  receives  data  packets  from  the  ground  laptop,  transmits  packets  to  the  ground 
and  other  satellites,  and  calls  the  state  determination  and  housekeeping  routines.  Some  of 
the  commands  that  can  be  sent  to  a  SPHERE  do  not  make  sense  in  the  simulation.  For 
example,  a  watchdog  timer  in  the  flight  code  periodically  checks  to  see  if  the  processor  is 
still  running.  If  not,  it  will  reset  the  processor.  This  capability  is  not  reflected  in  the  simu¬ 
lation  since  is  not  needed  to  evaluate  guest  scientist  code.  Therefore,  there  is  no  RESET 
command  that  causes  the  watchdog  timer  to  automatically  reset  the  processor,  even  though 
there  is  in  the  actual  SPHERES  system. 

4.6.2  Communications 

While  the  physical  communications  links  are  different  from  the  operational  system,  the 
communications  protocols  are  not.  The  only  difference  between  simulation  and  flight  sys¬ 
tems  is  that  the  low-level  reads  and  writes  to  hardware  were  replaced  with  the  receiving  or 
sending  of  signals.  The  formatting  of  messages  into  packets  for  transmission  as  single 
bytes  remains  unchanged.  This  includes  the  calculation  of  checksums  and  the  use  of  a 
token  ring  protocol.  While  there  is  no  real  need  to  send  a  message  as  several  bytes  in  the 
simulation,  or  to  compute  checksums  since  there  will  be  no  bit  errors  (although  this  could 
be  simulated),  it  is  desirable  to  do  so  since  it  keeps  the  timing  behavior  similar.  If  mes¬ 
sages  were  sent  as  a  single  signal,  the  relative  processing  time  between  the  four  software 
sections  could  change.  Furthermore,  confining  adaptations  to  a  few  low-level  functions 
ensured  that  few  changes  are  necessary  when  flight  code  is  updated.  Another  characteris¬ 
tic  of  communications  that  was  represented  is  that  when  one  SPHERE  sends  a  packet,  all 
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other  satellites  will  receive  it  and  must  determine  from  the  packet  header  whether  it  was 
meant  for  them.  This  maintains  the  same  relative  communications  processing  loads 
between  separate  satellites. 

4.6.3  Modifications  to  SPHERES  Code 

A  useful  feature  of  the  simulator  is  the  capability  of  providing  the  flight  code  with  perfect 
knowledge  of  the  SPHERE’S  state.  This  can  be  accomplished  by  receiving  the  state 
directly  from  the  dynamics  simulator,  bypassing  the  metrology  simulator.  This  allows  us 
to  investigate  the  best-case  performance  of  formation  flying  algorithms.  Perfect  state 
knowledge  eliminates  the  ambiguity  between  poor  performance  due  to  a  flawed  algorithm 
and  due  to  sensor  limitations. 

Other  modifications  to  flight  code  did  not  offer  any  benefits,  but  were  unavoidable  to 
allow  for  compatibility  with  the  GSS.  First,  in  the  SPHERES  flight  code,  the  programmer 
must  explicitly  instruct  the  operating  system  when  interrupts  may  be  preempted  by  higher 
priority  interrupts.  This  is  called  nesting  of  interrupts.  By  default,  this  feature  is  disabled 
in  the  flight  system.  However,  to  ensure  accurate  thruster  pulse-width  resolution,  the  pro¬ 
pulsion  interrupt  must  be  able  to  interrupt  the  controller.  Thus,  a  call  to  a  function  called 
NEST_INT  is  made  at  the  start  of  the  controller  interrupt,  and  a  call  to  UN_NEST  is  made 
at  the  end.  In  the  GSS,  these  calls  are  unnecessary  since  nesting  of  interrupts  occurs  auto¬ 
matically  because  the  interrupts  are  actually  coded  as  prioritized  processes.  The  message 
dispatcher,  which  calls  the  thruster  actuator,  runs  at  a  higher  priority  than  the  controller,  so 
preemption  is  automatic.  Furthermore,  the  flight  versions  of  the  NEST_INT  and 
UN_NEST  calls  contain  assembly  language  routines  that  are  not  compatible  with 
GFLOPS.  The  GFLOPS  SPHERES  Simulator  redefines  these  functions  as  "dummy"  rou¬ 
tines.  This  enables  guest  investigator  algorithms  to  be  compatible  with  both  the  GSS  and 
the  SPHERES  hardware. 

The  function  that  collects  metrology  data  was  rewritten.  For  the  prototype  SPHERES,  the 
function  tt  8_get  collects  metrology  data  from  individual  bytes  sent  from  the  Tattletale  8 
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processor.  However,  in  the  simulation,  a  metrology  reading  is  returned  in  full  in  one  sig¬ 
nal.  This  was  done  to  simplify  communications  between  the  metrology  simulator  and  the 
SPHERE  module,  and  to  avoid  tying  the  design  of  the  metrology  simulator  to  the 
SPHERES  code.  Thus,  tt8_get  was  adapted  to  handle  the  new  data  format. 

A  problem  with  the  SPHERES  flight  code  is  that  various  pointers  exist  that  point  to  spe¬ 
cific  parts  of  memory  as  defined  in  the  file  main.h.  These  include  the  addresses  of  various 
registers  that  do  not  exist  in  the  SPHERE  module  (eg.  for  communications  ports,  flash 
memory,  etc.).  If  these  non-existent  registers  were  written  to,  the  simulation  would 
behave  unpredictably  and  would  probably  crash.  To  alleviate  this  problem,  while  not 
modifying  references  to  these  registers  in  the  SPHERES  flight  code,  these  pointers  were 
reset  to  point  to  memory  that  is  dynamically  allocated  when  the  SPHERE  module  starts. 
The  writes  to  memory  can  still  occur,  but  they  will  have  no  effect  other  than  to  change  the 
values  held  in  these  dummy  registers.  Many  of  these  registers  control  secondary  systems 
such  as  LED  indicators,  so  accurate  implementation  is  not  required.  Using  dummy  regis¬ 
ters  allows  us  to  minimize  modifications  to  guest  scientist  code,  ensuring  that  the  flight 
and  simulation  code  remain  compatible. 

As  mentioned  earlier,  communications  had  to  be  modified  to  make  them  compatible  with 
OSE  interprocess  communications.  In  particular,  the  function  send_com  ( int  port, 
unsigned  char  out_char)  which  writes  data  to  the  hardware  output  register,  had 
to  be  rewritten.  The  integer  argument  specifies  the  destination:  the  ground  laptop,  other 
SPHERES,  or  the  field  programmable  gate  array  (FPGA),  while  the  second  argument  is  a 
single  byte  of  data.  Intersatellite  communications  are  sent  to  all  other  satellites  via  OSE 
signals,  while  STL  communications  are  sent  to  all  satellites,  as  well  as  the  laptop  applica¬ 
tion  running  on  a  support  PC.  For  communication  with  the  FPGA,  the  modified  function 
checks  the  char  argument  and  sends  either  a  global  metrology  request  to  the  metrology 
simulator,  an  IMU  request,  or  both.  The  input  function  get_com  is  unchanged  since 
incoming  data  is  buffered  in  global  arrays  by  the  communications  interrupt.  The 
get_com  function  simply  accesses  these  arrays. 
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Besides  the  modifications  mentioned  here,  a  number  of  small  changes  had  to  be  made  to 
various  header  (.h)  files.  These  modifications  were  necessary  so  that  some  of  the  flight 
software  files  (written  in  C)  could  included  by  other  GSS  files  (written  in  C++).  These 
changes  do  not  affect  the  functioning  of  the  SPHERES  code  in  the  simulation. 

In  order  to  allow  the  flight  code  to  fit  seamlessly  into  the  simulation,  some  "wrapper"  code 
was  needed.  For  example,  the  SPHERE  needs  to  search  for  the  process  IDs  of  the  com¬ 
munications  manager  and  of  other  units,  so  it  can  send  signals  to  them.  The  wrapper  code 
also  sends  the  initial  state  of  the  unit  to  the  dynamics  simulator.  Furthermore,  the  timing 
and  priority  of  the  processes  are  specified  in  the  wrapper  code.  The  wrapper  code  contains 
the  elements  of  the  GRRDE  module  architecture,  such  as  the  block  manager  and  input 
arbiter. 

4.7  Communications  Manager 

The  communications  manager  module  facilitates  message  passing  between  the  SPHERES 
module  and  the  simulated  laptop  application.  The  communications  manager  exchanges 
signals  with  a  bridge  application  (named  OSEbridge)  running  on  an  OSE  soft  kernel  on 
the  support  PC.  To  complete  the  final  leg  of  the  communications  channel,  a  named  pipe  is 
established  between  OSEbridge  and  the  laptop  program.  A  pipe  is  a  section  of  shared 
memory  that  Windows  processes  can  use  to  communicate.  OSEbridge  parses  information 
between  the  formats  needed  for  these  two  communications  channels.  OSEbridge  supports 
two  pipes  to  PC  applications,  one  to  the  3-D  viewer  and  another  to  the  simulated  laptop 
command  interface.  The  3-D  viewer  draws  SPHERE  positions  using  truth  data  obtained 
form  the  dynamics  simulator. 

OSEbridge  also  enables  the  automatic  loading  and  starting  of  simulation  modules  upon 
system  start-up.  The  user  puts  the  names  of  the  software  modules  to  load  into  a  file  and 
OSEbridge  sends  these  names  to  a  process  running  on  the  embedded  hardware,  which  then 
loads  and  optionally  starts  the  appropriate  modules. 
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The  communications  manager  was  needed  as  an  intermediate  step  between  the  SPHERE 
module  and  OSEbridge  due  to  the  limited  communications  bandwidth  of  OSEbridge.  The 
OSEbridge  must  compete  for  access  to  the  CPU  with  all  of  the  other  PC  applications, 
including  the  3-D  viewer  and  the  laptop  command  interface.  Running  OSEbridge  at  a 
higher  priority  than  these  other  applications  resulted  in  very  slow  system  performance. 
However,  when  it  was  run  at  the  same  priority  as  these  other  processes,  the  time  that  it 
spent  waiting  for  its  next  chance  to  use  the  CPU  was  too  great  to  support  the  real-time 
communications  between  the  SPHERES  and  the  laptop  command  window.  In  testing  it 
was  found  that  OSEbridge  would  sleep  for  up  to  100  ms.  This  delay  is  unnacceptable 
because  when  receiving  a  packet  from  the  ground  laptop  (or  from  another  SPHERE),  the 
SPHERE  has  a  4  ms  second  maximum  timeout  in  between  bytes,  after  which  it  is  assumed 
that  there  has  been  a  communications  error  and  the  rest  of  the  packet  is  ignored.  In  order 
to  avoid  timeout  errors  due  to  the  delays  experienced  by  OSEbridge,  it  was  realized  that 
packets  should  be  sent  through  OSEbridge  in  full,  instead  of  as  individual  bytes.  How¬ 
ever,  as  already  mentioned,  a  requirement  of  the  simulator  architecture  was  to  avoid 
changes  to  high-level  SPHERES  flight  code.  To  preserve  this  objective  and  provide  reli¬ 
able  communications  with  the  laptop  interface,  an  intermediary  node  was  needed  on  the 
communications  path.  This  entity,  the  communications  manager,  allows  signals  to  be  sent 
between  itself  and  OSEbridge  as  whole  packets,  and  between  the  SPHERE  module  and 
itself  as  single  bytes. 

The  communications  manager  is  made  up  of  two  processes,  the  satellite-to-ground  (STG) 
and  the  ground-to-satellite  (GTS)  communications  managers.  The  STG  communications 
manager  uses  the  SPHERES  get_packet  function  to  collect  packets  from  the  individ¬ 
ual  bytes  sent  by  the  SPHERES.  Once  a  full  packet  is  received,  it  sends  it  to  OSEbridge  as 
one  signal.  Signals  intended  for  the  laptop  are  forwarded  to  the  other  SPHERES,  mimick¬ 
ing  broadcast  communication.  The  other  SPHERES  must  receive  and  discard  these  pack¬ 
ets.  The  GTS  communications  manager  receives  packet  signals  from  the  laptop,  breaks 
them  up  into  bytes  and  sends  them  the  SPHERES. 
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The  communications  manager  filters  SPHERES  telemetry  that  is  forwarded  to  the  laptop. 
This  filtering  is  necessary  because  with  several  SPHERES  in  the  simulation,  the  OSE- 
bridge  communications  bandwidth  gets  used  up.  When  the  communications  manager 
receives  a  telemetry  packet  from  a  SPHERE,  it  checks  its  type  (eg.  master  position,  slave 
angular  rate),  and  compares  it  to  the  filtering  rules.  At  compile  time,  the  user  can  choose 
to  filter  (ie.  not  send)  all,  none,  or  some  fraction  of  each  type  of  telemetry  message.  How¬ 
ever,  the  signals  will  still  get  passed  on  to  the  other  SPHERES  (which  will  discard  them 
since  they  are  meant  for  the  ground  laptop).  Command  and  token  messages  are  not  fil¬ 
tered.  Messages  passing  in  the  other  direction,  from  the  laptop  to  the  SPHERE,  are  never 
filtered. 

4.8  Simulation  Viewer 

Running  simulations  can  be  visualized  using  a  3-D  viewer  developed  for  the  GFLOPS 
SPHERES  Simulator.  The  viewer  uses  OpenGL  graphics  libraries  and  shows  the  motion 
of  SPHERES  units  in  the  test  space.  A  screen-shot  of  the  viewer  is  provided  in  Figure  4.4. 
The  viewer  receives  state  updates  from  the  dynamics  simulator  every  100  ms.  These  are 
delivered  by  a  standard  GRRDE  message  contract.  Thus,  it  can  display  the  motion  of 
SPHERES  at  a  rate  of  10  frames/sec.  Lighting  helps  provide  a  sense  of  perspective. 
Ultrasound  beacons  are  drawn  as  cylinders  with  a  protruding  line  denoting  their  pointing 
directions.  Thus,  one  can  track  where  the  SPHERES  are  with  respect  to  the  test  space. 

The  user  can  choose  from  several  preset  views  or  he  can  manually  alter  the  viewpoint. 
Three  modes  exist  for  scene  navigation.  Zooming  moves  the  viewpoint  closer  or  farther 
from  the  image  along  the  line  of  sight.  Flying  moves  the  viewpoint  perpendicular  to  the 
line  of  sight.  Rotating  rotates  the  viewpoint  around  the  image.  Each  of  these  scene  navi¬ 
gations  are  executed  with  the  mouse. 

Live  simulations  can  be  viewed  in  real-time.  They  can  also  be  recorded  for  later  playback 
by  choosing  to  log  the  satellite  state  data  to  a  text  file.  Thus,  with  a  copy  of  the  viewer  and 
a  simulation  log,  guest  investigators  can  visualize  the  performance  of  their  algorithms 
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remotely.  Because  a  timer  ensures  that  data  is  read  from  the  log  at  the  same  rate  as  it  was 
written,  playback  speed  is  insensitive  to  computer  performance. 

The  viewer  also  allows  the  user  to  send  disturbance  signals  to  the  dynamics  simulator,  to 
request  that  force  and  torque  histories  be  sent  from  the  dynamics  simulator  and  saved  to 
file,  and  to  reset  the  simulation. 

4.9  Simulated  SPHERES  Laptop  GUI 

An  application  was  created  to  simulate  the  functioning  of  the  laptop  that  communicates 
with  the  SPHERES.  The  simulated  laptop  interface  is  shown  below  in  Figure  4.5.  This 
application  displays  telemetry  and  debug  information  from  the  SPHERES  and  the  user  can 
choose  from  a  list  of  commands  to  send  to  a  SPHERE.  The  appearance  of  this  application 
could  be  altered  to  track  changes  in  the  flight  version.  Alternatively,  using  the  code  for  the 


78 


SIMULATOR  ARCHITECTURE  AND  MODULES 


Figure  4.5  Simulated  SPHERES  Laptop  GUI. 

simulated  GUI  as  a  guide,  the  final  flight  GUI  could  be  adapted  for  communications  with 
the  GSS. 

The  core  logic  that  processes  communications  to  and  from  SPHERES  was  adapted  from  a 
version  of  the  laptop  application  that  has  been  used  with  the  prototype  hardware.  This  was 
done  to  ensure  consistent  creation  and  processing  of  packets.  In  particular,  because  the 
data  received  from  the  units  is  saved  in  the  same  format,  the  telemetry  created  during  test¬ 
ing  on  the  GFLOPS  testbed  can  be  reduced  and  analyzed  using  MATLAB  scripts  created 
for  flight  telemetry.  Several  parts  of  the  application  logic  required  modification.  For 
example,  since  communications  between  the  laptop  and  the  communications  manager  use 
full  packets,  instead  of  individual  bytes,  these  differences  are  reflected  in  some  low-level 
functions. 
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4.10  CPU  Load  Profiler 

The  OSE  Illuminator  debugger  allows  users  to  measure  CPU  utilization.  A  continuously 
updating  graph  of  load  percentages  provides  a  good  summary  of  CPU  processing  time,  as 
shown  in  Figure  4.6.  Another  option  is  to  do  a  process  level  load  measurement,  where  the 
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Figure  4.6  CPU  load  measurement. 


load  for  each  process  is  overlayed  on  a  color-coded  graph.  The  output  window  for  process 
level  load  measument  is  given  in  Figure  4.7.  Alternatively,  the  data  can  be  displayed  and 
saved  as  a  text  listing. 

The  profiler  measures  the  relative  processing  needs  of  the  processes  in  the  system.  This 
can  be  used  to  analyze  the  effects  of  design  decisions.  The  processing  requirements  of  the 
thruster  dispatch  function  are  not  expected  to  vary  with  different  control  algorithms, 
assuming  the  Standard  Control  Interface  (see  Section  2.4.2)  is  used.  The  communication 
process’  processing  needs  will  vary  with  the  amount  of  traffic,  but  are  is  not  expected  to 


80 


SIMULATOR  ARCHITECTURE  AND  MODULES 


Figure  4.7  Process  level  load  measurement. 


make  up  a  significant  portion  of  the  processing.  The  greatest  amount  of  variability  is 
likely  to  occur  with  the  controller  process,  since  this  code  will  change  substantially  from 
test  to  test.  There  could  also  be  large  differences  in  background  processing  requirements. 
If  the  Direct  Control  Interface  is  employed,  the  processor  utilization  of  each  process  could 
vary  significantly  for  different  guest  scientist  code.  With  the  Custom  Control  Interface  it 
is  not  possible  to  compare  one  set  of  code  to  another,  as  there  could  be  a  completely  differ¬ 
ent  set  of  processes,  but  we  can  still  observe  the  absolute  load  on  the  processor. 

Since  the  simulator  hardware  and  operating  system  are  not  the  same  as  the  flight  versions, 
the  flight  processor  utilization  may  vary  from  our  measurements.  In  order  to  draw  conclu¬ 
sions  about  performance  on  the  flight  hardware,  we  need  to  be  able  to  compare  the  proces¬ 
sors  in  the  two  systems.  The  SPHERES  flight  hardware  features  a  Texas  Instruments 
digital  signal  processor,  the  TMS320C6701,  that  runs  the  flight  software.  Since  this  is  a 
DSP,  it  is  optimized  for  vector  or  parallel  computations.  For  this  reason,  it  has  eight  func¬ 
tional  units  that  can  perform  calculations  simultaneously  [TI,  2000].  The  C6701  has  four 
fixed-/floating-point  arithmetic  logic  units  (ALUs),  two  fixed-point  ALUs,  and  two  fixed- 
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/floating-point  multipliers.  The  ALUs  perform  32-bit  calculations,  while  the  multipliers 
have  16-bit  inputs  and  32-bit  outputs.  Running  at  167  MHz,  the  TMS320C6701  takes  6  ns 
to  perform  a  cycle.  With  the  six  floating-point  units  operating  in  parallel,  a  theoretical 
maximum  performance  of  1  x  109  floating-point  operations  per  second  (FLOPS)  is  possi¬ 
ble  (six  operations  in  6  ns).  However,  this  maximum  performance  would  only  be 
approached  for  problems  that  can  exploit  the  parallel  processing  throughput  of  the  DSP 
(ie.  those  that  allow  six  floating-point  calculations  to  be  made  in  parallel).  This  is  com¬ 
mon  in  DSP  applications,  where  there  may  be  signals  coming  in  from  twelve  or  more 
channels,  but  it  is  not  the  case  for  the  SPHERES  testbed.  The  majority  of  calculations  will 
be  too  simple  to  break  up  into  six  pieces,  and  the  result  of  one  calculation  will  often  be 
needed  before  the  next  can  start.  For  this  reason,  it  is  not  expected  that  the  theoretical 
limit  of  1  x  109  FLOPS  will  be  approached  on  the  SPHERES  hardware. 

The  GFLOPS  testbed  relies  on  a  more  general  purpose  processor,  the  IBM  PowerPC  750, 
running  at  400  MHz.  This  processor  has  two  fixed  point  units  and  one  floating  point  unit 
[IBM,  2001].  The  floating  point  unit  is  able  to  perform  a  single-precision  (32-bit)  multi- 
ply-add  operation  in  one  cycle.  A  multiply-add  operation  is  a  ternary  operation  of  the 
form: 


a  ±  be  (4.26) 

Thus,  since  a  multiply-add  accounts  for  two  floating  point  operations,  and  the  processor  is 
running  at  400  MHz,  the  theoretical  peak  performance  of  a  GFLOPS  processor  is  800 
MFLOPS. 

Although  GFLOPS  will  never  perform  at  800  MFLOPS,  it  is  likely  to  be  closer  to  its  limit 
than  the  SPHERES  DSP  to  its  own,  since  the  SPHERES  processor  requires  higher  paral¬ 
lelism  in  the  computation  to  make  the  most  of  its  resources.  Despite  the  lower  peak  per¬ 
formance  of  the  GFLOPS  processors,  we  expect  that  they  could  have  a  higher  effective 
performance  when  running  SPHERES  code.  To  obtain  a  quantitative  comparison  of  the 
speeds  of  the  processors  would  require  measuring  the  running  time  of  SPHERES  code  on 
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both.  Even  if  we  cannot  draw  conclusions  from  the  running  time  on  the  GFLOPS  hard¬ 
ware,  we  can  expect  that  the  relative  processing  time  of  each  process  will  be  similar.  For 
example,  if  the  controller  process  is  using  most  of  the  processing  power  in  the  simulator, 
we  expect  to  see  the  same  behavior  if  the  code  were  run  on  SPHERES. 

Another  issue  that  must  be  considered  when  attempting  to  compare  processor  utilization  is 
the  fact  that  time  delays  take  the  same  amount  of  time  on  any  processor.  For  example,  the 
timeout  that  occurs  when  a  SPHERE  is  waiting  for  a  communications  byte  from  another 
SPHERE  that  does  not  arrive  (further  explored  in  Section  5.2.2),  will  take  4  ms  no  matter 
what  type  of  processor  is  being  used.  In  the  case  of  STS  communications  being  received 
in  the  controller  process,  the  majority  of  this  time  will  be  counted  towards  CPU  utilization 
by  the  controller  process  (since  it  only  gets  interrupted  by  the  thruster  and  communica¬ 
tions  interrupts,  which  do  not  take  much  processing  time).  Hence,  we  cannot  directly  con¬ 
vert  processor  utilization  times  using  a  multiplication  factor,  since  the  factor  would 
depend  on  the  amount  of  communications  timeouts  in  the  code.  One  solution  would  be  to 
estimate  the  amount  of  processor  utilization  that  is  due  to  time  delays  on  the  GFLOPS  sys¬ 
tem,  subtract  this  amount,  then  use  a  factor  (assuming  we  have  done  a  calibration)  to  pre¬ 
dict  the  utilization  due  to  the  rest  of  the  code  on  the  SPHERES  hardware,  and  finally  add 
the  timing  delays  back  in. 

4.11  Memory  Usage 

The  GSS  is  also  tasked  with  investigating  memory  usage  by  SPHERES  code.  Flight  code 
must  not  use  more  memory  than  is  available  from  the  SPHERES  hardware.  While  the 
GFLOPS  processors  have  access  to  256  MB  of  RAM,  the  SPHERES  avionics  have  only 
16  MB.  Thus,  limitting  the  amount  of  memory  available  to  the  SPHERE  module  would 
make  the  simulator  more  representative  of  the  target  system. 

There  are  several  ways  that  memory  is  stored  for  a  computer  program.  Global  and  static 
variables  are  stored  for  as  long  as  a  program  runs.  Local  variables  are  allocated  from  the 
stack  when  a  function  is  called.  The  heap  is  used  for  dynamic  memory  allocation  (mem- 
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ory  that  is  allocated  only  at  run-time).  SPHERES  flight  code  makes  extensive  use  of  each 
of  these  types  of  memory  allocation.  In  addition  to  storage  of  program  variables,  the  pro¬ 
gram  execution  code  must  also  be  stored  in  RAM 

When  a  process  is  created  in  OSE,  the  size  of  the  stack  is  specified.  Therefore,  we  can 
limit  the  stack  memory  available  to  each  SPHERES  process.  However,  this  is  not  repre¬ 
sentative  of  the  situation  that  actually  occurs  with  the  SPHERES  flight  system.  Here,  the 
total  memory  available  is  shared  between  all  interrupts. 

In  OSE,  there  is  one  heap  for  each  memory  segment.  Because  all  SPHERES  processes  are 
part  of  the  same  block,  they  share  the  same  memory  segment  and  therefore  the  same  heap. 
Furthermore,  since  the  other  OSE  or  GRRDE  processes  that  use  the  same  memory  seg¬ 
ment  do  not  allocate  memory  dynamically,  all  of  the  memory  allocated  from  the  heap 
belongs  to  SPHERES  processes. 

One  method  for  verifying  that  the  SPHERES  code  does  not  use  more  than  16  MB  would 
be  to  estimate  the  amount  of  storage  needed  for  non-dynamic  memory,  then  bound  the  size 
of  the  heap  so  that  the  total  memory  never  exceeds  16  MB.  Limiting  the  size  of  the  heap 
would  result  in  the  SPHERE  module  crashing  if  the  heap  fills  up.  Another  option  would 
be  to  directly  track  dynamic  memory  inside  the  dynamic  memory  allocation  and  dealloca¬ 
tion  functions.  The  amount  of  global  and  static  memory  could  be  easily  determined.  Esti¬ 
mating  the  amount  of  stack  memory  needed  would  entail  summing  the  maximum 
requirements  for  each  interrupt.  This  could  be  done  by  determining  at  which  point  in  each 
process  the  most  local  memory  is  needed  (for  all  levels  of  the  function  call  stack).  To 
determine  the  size  of  the  executable  flight  code,  we  could  examine  the  compiled  memory 
image  (by  getting  a  member  of  the  SPHERES  team  to  build  the  code). 


4.12  Summary 

This  chapter  gave  an  detailed  account  of  the  GFLOPS  SPHERES  Simulator.  The  objec¬ 
tives  explained  at  the  start  of  the  chapter  helped  to  understand  the  reasoning  behind  many 
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of  the  design  decisions  that  were  later  outlined.  The  three  simulator  modules  were 
described  with  emphasis  on  their  roles,  their  features,  and  their  interfaces.  The  SPHERE 
module  was  presented  next,  and  care  was  taken  to  compare  its  design  and  functioning  to 
that  of  the  flight  code.  The  adaptations  that  had  to  be  made  to  SPHERES  code  to  allow  it 
to  run  in  the  simulator  were  listed  and  their  effect  on  the  simulator’s  accuracy  were  ana¬ 
lyzed.  It  was  discussed  how  the  communications  manager  helps  alleviate  bandwidth  prob¬ 
lems  for  communications  between  the  embedded  hardware  and  the  support  PC.  The  3-D 
viewer  and  the  simulated  laptop,  two  simulation  monitoring  applications  that  run  on  the 
PC,  were  also  introduced.  Finally,  methods  for  measuring  processor  load  and  memory 
usage  were  outlined.  We  saw  that  determining  processor  utilization  is  easily  done  with 
tools  provided  by  OSE,  while  memory  estimation  mostly  has  to  be  done  manually  by  ana¬ 
lyzing  code. 

The  next  chapter  will  demonstrate  the  use  of  the  simulator  for  a  set  of  representative  sce¬ 
narios.  The  results  discussed  in  that  chapter  will  allow  us  to  guage  the  usefulness  and 
accuracy  of  the  simulator. 


Chapter  5 

* 

SIMULATION  RESULTS 


5.1  Introduction 

This  chapter  presents  the  results  of  several  simulations  that  illustrate  the  performance  of 
the  GFLOPS  SPHERES  Simulator.  A  leader-follower  simulation  demonstrates  several  of 
the  capabilities  of  the  GSS,  including  inter-SPHERE  communications,  CPU  utilization 
measurement,  and  force  recording.  A  collision  test  and  a  passive  docking  test  show  the 
simulator’s  abilities  in  these  areas.  A  cooperative  docking  test  on  the  GSS  is  used  to  com¬ 
pare  the  motion  observed  with  that  obtained  with  the  same  control  code  on  the  SPHERES 
air  table. 


5.2  Leader-Follower  Simulation 

In  order  to  test  the  intersatellite  communications  capabilities  of  the  GFLOPS  SPHERES 
Simulator,  a  simulation  scenario  was  developed  that  involved  a  "leader"  SPHERE  execut¬ 
ing  a  predetermined  profile,  while  a  "follower"  SPHERE  attempted  to  mimic  the  motion 
of  the  leader  (with  an  offset  to  avoid  collisions).  The  leader  transmitted  its  state  to  the  fol¬ 
lower  at  a  rate  of  10  Hz  and  the  follower  used  this  (minus  an  offset  of  30  cm)  as  its  target 
state.  The  predetermined  profile  took  the  form  of  a  square  of  40  cm  side  length  parallel  to 
the  XY  plane.  The  leader  was  commanded  to  remain  at  each  comer  of  the  square  for  10 
seconds.  No  noise  was  added  to  either  the  thruster  firings  or  the  metrology  readings. 
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The  Standard  Control  Interface  was  used  for  this  simulation.  The  custom  code  placed  in 
the  function  process_maneuverlis  t  is  listed  in  Appendix  B.  It  should  be  noted  that 
the  function  propagate_state  from  the  SPHERES  flight  code,  used  to  update  the 
state  every  time  an  IMU  measurement  is  received,  was  modified  to  take  into  account 
acceleration  due  to  thruster  firings.  A  record  is  kept  listing  the  time  each  thruster  has  been 
on  since  the  last  IMU  update.  This  is  used  to  find  the  average  force  exerted  on  the 
SPHERE  by  its  thrusters.  This  modification  was  done  to  obtain  good  results,  since  accel¬ 
erometer  measurements  were  not  being  used. 

5.2.1  Motion  Observed: 


Figure  5.1  Leader  trajectory. 

The  leader’s  trajectory  is  plotted  in  Figure  5.1.  We  see  that  the  leader  traced  out  a  clean 
square,  with  some  oscillation  at  the  comers.  The  oscillations  are  primarily  due  to  inaccu- 
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Figure  5.2  Follower  trajectory. 

racies  in  the  state  propagation  that  the  SPHERE  performs  in  between  global  metrology 
updates.  Refinement  of  control  parameters  could  also  help  to  eliminate  some  of  the  over¬ 
shoot.  The  follower’s  trajectory,  in  Figure  5.2,  was  significantly  worse.  The  edges  of  the 
square  are  not  straight,  and  the  oscillations  at  the  comers  are  larger.  One  might  wonder 
why  the  follower’s  path  is  not  identical  to  that  of  the  leader,  since  it  was  controlling  to  the 
leader’s  state.  The  reason  for  this  is  that  the  leader  was  controlling  to  a  target  state  that 
differs  from  its  actual  state.  Therefore,  the  leader  and  follower  were  controlling  to  differ¬ 
ent  target  states.  Any  deviations  from  the  desired  trajectory  were  transmitted  to  the  fol¬ 
lower  as  its  target  state  and  were  amplified  in  the  follower.  This  is  especially  clear  in 
Figure  5.3,  which  shows  the  positions  of  both  the  leader  and  follower  along  the  x-axis 
with  respect  to  time.  We  see  that  at  the  end  of  the  plot,  the  leader  overshot  its  final  target 
state  and  oscillated  before  settling  down.  This  overshoot  and  oscillation  was  magnified  in 
the  follower.  A  further  reason  for  the  poorer  quality  of  the  follower’s  trajectory  is  that  the 
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Figure  5.3  Time  history  of  leader  and  follower  position  along  x-axis  (offset  subtracted  out). 

leader’s  estimated  state  was  not  equal  to  its  actual  state.  Recall  the  discussion  in 
Section  4.4  of  the  fact  that  the  SPHERE’S  position  determination  from  global  metrology 
measurements  is  never  perfect,  even  when  no  noise  is  added  to  the  measurements.  There¬ 
fore,  any  errors  in  state  estimation  were  also  transmitted  to  the  follower  as  its  target  state. 
This  can  be  seen  clearly  at  the  start  of  the  plot,  where  the  leader  made  an  initial  adjustment 
because  a  slight  error  in  its  position  estimate  caused  it  to  believe  that  it  was  not  at  the 
desired  starting  point.  The  follower,  which  had  to  deal  with  its  own  position  estimation 
error,  as  well  as  that  of  the  leader,  had  a  harder  time  controlling  to  the  desired  state. 

5.2.2  CPU  Utilization 

The  CPU  utilization  characteristics  for  the  leader  and  follower  are  shown  in  Figure  5.4, 
with  the  utilization  broken  down  by  process.  These  measurements  were  done  using  the 
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Figure  5.4  Leader  and  follower  CPU  loading  comparison. 

Profiler  application  that  conies  with  OSE  Illuminator,  as  described  in  Section  4.10.  One 
notices  that  adding  up  the  percentages  for  each  SPHERE  results  in  a  total  slightly  less  than 
100%.  This  is  due  to  the  fact  that  there  were  other  GRRDE  and  OSE  processes  executing 
that  are  not  listed  in  the  figure.  We  see  that  the  thruster  interrupt  and  communications  pro¬ 
cess  do  not  utilize  much  processing  time.  The  interesting  comparison  is  between  the  con¬ 
troller  processes.  While  the  leader’s  controller  process  required  only  0.2%  of  the  available 
processing  time,  the  follower’s  utilized  almost  20%,  or  100  times  more.  This  is  explained 
by  the  fact  that  the  follower  received  communications  packets  from  the  leader,  while  the 
leader  did  not.  When  extracting  data  from  the  arrays  that  hold  communications  data,  there 
is  a  4ms  timeout.  In  other  words,  the  follower  keeps  on  extracting  data  from  the  array 
until  such  time  that  the  array  is  continuously  empty  for  4ms.  This  is  done  because  the 
communications  process  could  be  placing  data  into  the  array  at  the  same  time  that  the  con¬ 
troller  is  extracting  it.  The  timeout  is  meant  to  ensure  that  all  of  the  data  for  a  particular 
message  will  be  received  during  the  same  pass  through  the  controller  code.  The  controller 
process  was  executing  at  a  rate  of  50  Hz,  corresponding  to  20  ms  between  consecutive  acti- 
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vations.  Therefore,  the  4ms  accounts  for  the  20%  CPU  load  of  the  controller  process. 
Any  free  time  was  used  by  background  processing.  Again,  the  majority  of  this  processor 
utilization  was  due  to  communications  timeouts. 

5.2.3  Force  History 

For  a  separate  run,  where  the  same  desired  trajectory  was  used,  the  leader’s  force  history 
was  recorded  in  order  to  demonstrate  the  force  and  torque  recording  capabilities  of  the 
simulator.  For  this  run,  in  order  to  obtain  cleaner  data,  the  leader  was  provided  with  per¬ 
fect  state  information  from  the  dynamics  simulator.  The  force  history  is  shown  in 
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Figure  5.5  Force  history  for  leader  tracing  out  a  square. 

Figure  5.5.  At  the  scale  of  this  figure,  most  of  the  thruster  firings  appear  on  top  of  each 
other,  giving  the  appearance  of  a  long  pulse,  when  they  are  all  in  fact  very  short  pulses. 
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We  can  recognize  the  thruster  firings  associated  with  each  of  the  sides  of  the  square.  The 
SPHERE  started  off  by  moving  in  the  +Y  direction,  then  in  the  +X  direction,  followed  by 
-Y  and  -X.  For  each  side,  there  was  an  acceleration  period,  followed  by  a  deceleration, 
and  some  further  thrusts  that  damped  out  any  oscillations. 

5.3  SPHERE-SPHERE  Collision  Simulation 

A  simple  collision  test  was  done  with  two  SPHERES  moving  towards  each  other  at  an 
angle.  No  control  was  used  for  this  test  (ie.  no  thrusters  were  fired).  Since  their  docking 
ports  were  not  facing  each  other,  they  were  expected  to  collide  and  bounce  off  of  each 
other.  Because  the  coefficient  of  restitution  for  SPHERE-SPHERE  collisions  was  set  at 
0.5,  the  units  were  expected  to  have  relative  velocities  of  separation  of  half  the  magnitude 
of  their  relative  velocity  of  approach.  The  motion  observed  during  the  test  is  shown  in 
Figure  5.6.  The  SPHERES  started  at  the  bottom  of  the  figure  and  moved  upwards.  They 


Figure  5.6  Motion  for  collision  between  two  SPHERES. 
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collided  when  their  centers  were  20  cm  apart,  equal  to  two  radii  of  the  SPHERES.  The 
units  then  fly  apart  with  the  expected  change  in  their  velocities. 

5.4  Passive  Docking  Simulation 

In  order  to  test  the  docking  capabilities  of  the  GFLOPS  SPHERES  simulation,  a  simple 
test  was  conducted  with  two  SPHERES  moving  towards  each  other  with  their  docking 
ports  facing.  The  SPHERES  began  with  a  large  position  offset  along  the  X  axis,  as  well  as 
a  5  cm  offset  along  the  Y  axis.  They  were  given  initial  velocities  parallel  to  the  X  axis 
(one  of  +5  cm/s,  the  other  -50  cm/s).  Again,  no  control  was  used  for  this  test.  Since  they 
were  offset  along  the  Y  axis,  we  expected  the  docked  SPHERES  to  rotate  about  the  Z  axis 
due  to  conservation  of  angular  momentum.  In  Figure  5.7,  we  see  the  X  axis  motion.  The 


Figure  5.7  Motion  along  X  axis  for  docking  SPHERES. 


SPHERE  represented  by  the  blue  trace  moved  towards  the  other  at  a  higher  velocity.  Once 
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Figure  5.8  Motion  along  Y  axis  for  docking  SPHERES. 

they  collided,  they  stuck  together  with  a  distance  of  20  cm  between  them.  Conservation  of 
momentum  dictated  that  the  faster  moving  SPHERE  slowed  down,  while  the  other  sped  up 
by  the  same  amount.  Figure  5.8  depicts  the  Y  axis  motion  of  the  SPHERES.  After  the 
collision,  conservation  of  angular  momentum  resulted  in  rotation  about  the  Z  axis,  which 
is  reflected  in  the  oscillating  Y  positions.  The  oscillations  cannot  be  seen  in  Figure  5.7 
because  the  time  scale  is  much  shorter  than  in  Figure  5.8. 


5.5  Cooperative  Docking  Simulation 

A  form  of  cooperative  docking  was  tested  with  the  GFLOPS  SPHERES  Simulator.  It 
involved  a  leader  satellite  that  was  attempting  to  remain  in  one  spot  and  was  sending  its 
state  to  a  follower  satellite.  The  follower,  which  started  off  with  an  initial  offset  in  its  ori¬ 
entation  and  in  its  position  along  the  Y-axis,  was  supposed  to  dock  with  the  leader.  It  was 
to  do  this  by  first  rotating  90°  about  its  Z-axis,  then  eliminating  the  difference  in  their 
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positions.  Both  the  rotation  and  the  translation  parallel  to  the  Y-axis  were  designed  to  take 
the  form  of  a  raised  cosine.  A  raised  cosine  is  a  function  of  the  form: 


At)  =J{t0)+A 


1  -  COSO) 

2  ; 


(5.1) 


Figure  5.9  shows  the  shape  that  is  expected  when  a  raised  cosine  is  used  to  reach  a  new 


final  value. 

The  same  test  had  also  been  run  on  the  MIT  SSL  air  table  in  December  2000.  The  same 
code  was  used  for  the  GSS  test,  to  ensure  that  metrology  processing  and  control  of  the 
SPHERE  were  handled  identically.  The  motion  of  the  follower  for  the  air  table  and  the 
GSS  test  is  summarized  in  three  figures.  The  SPHERE’S  internal  state  estimates  were 
used  as  the  data  for  these  plots,  because  this  is  what  was  available  for  the  air  table  test. 
For  all  previous  plots  in  this  chapter,  truth  data  from  the  dynamics  simulator  was  used. 
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Figure  5.10  shows  the  initial  Z-axis  rotation.  Although  the  rotation  on  the  air  table  had  a 


Figure  5.10  Comparison  of  Z-axis  rotation  for  air  table  and  GSS. 


slightly  larger  overshoot,  the  curves  are  quite  close  to  each  other. 

Figure  5.11  shows  the  motion  parallel  to  the  Y-axis  as  a  function  of  time  for  both  tests. 
Again,  the  curves  are  similar  although,  towards  the  end  of  the  air  table  test,  the  SPHERE 
was  unable  to  get  a  good  global  metrology  measurement,  which  explains  the  horizontal 
line  at  the  end  of  that  test.  The  fact  that  the  other  SPHERE  did  not  have  this  trouble  indi¬ 
cates  that  the  metrology  simulator  did  not  exclude  enough  global  metrology  measure¬ 
ments.  This  was  essentially  due  to  the  fact  that  the  maximum  acceptable  receiver  angle 
was  set  to  be  too  large.  The  discrete  "stepped"  appearance  of  the  plots  is  due  to  the  fact 
that  the  SPHERE’S  estimate  of  its  position  was  only  updated  when  it  received  a  global 
metrology  measurement.  The  fact  that  there  are  more  steps  in  the  GSS  plot  is  further  indi¬ 
cation  that  the  metrology  simulator  was  providing  too  many  good  global  metrology  mea¬ 


surements. 
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Figure  5.11  Comparison  of  motion  parallel  to  Y-axis  for  air  table  and  GSS. 


Figure  5.12  Comparison  of  XY  plane  motion  for  air  table  and  GSS. 
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Figure  5.12  shows  the  motion  parallel  to  the  XY  plane  for  both  tests.  The  favorable  global 
metrology  measurements  explain  why  the  GFLOPS  data  is  cleaner  than  the  air  table  data. 
Their  paths  do  show  the  same  trends  though.  The  oscillation  at  the  end  of  GSS  test  is 
quite  large  because  the  follower  was  repeatedly  bouncing  off  of  the  leader  (their  docking 
ports  were  not  aligned). 


5.6  Summary 

This  chapter  presented  some  results  of  simulations  that  were  run  on  the  GFLOPS  testbed. 
A  leader- follower  square  profile  simulation  demonstrated  several  of  the  capabilities  of  the 
GSS,  including  inter-SPHERE  communications,  measurement  of  CPU  utilization,  and 
force  recording.  A  simple  collision  between  SPHERES  and  a  passive  docking  simulation 
proved  the  ability  of  the  GSS  to  detect  and  simulate  collisions  and  docks.  A  direct  com¬ 
parison  between  cooperative  docking  motion  obtained  with  the  same  control  code  on  the 
air  table  and  the  GSS  provided  evidence  of  the  usefulness  of  the  simulation  functions  of 
the  GSS. 
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Chapter  6 

CONCLUSIONS 


This  thesis  presented  the  GFLOPS  SPHERES  Simulator  (GSS).  This  chapter  begins  by 
summarizing  the  main  conclusions  that  were  drawn  in  the  previous  chapters.  It  then  ana¬ 
lyzes  the  usefulness  of  the  GSS  with  respect  to  the  three  control  interfaces.  Finally,  it  pre¬ 
sents  some  suggestions  for  future  work  on  the  GSS. 

6.1  Summary 

6.1.1  SPHERES 

The  SPHERES  testbed  will  allow  for  verification  of  satellite  formation  flight,  autonomy 
and  autonomous  rendezvous  and  docking  algorithms  designed  by  external,  "guest"  scien¬ 
tists.  SPHERES  will  operate  in  zero-gravity  inside  the  International  Space  Station  (ISS), 
an  environment  whose  characteristics  cannot  be  accurately  reconstructed  in  the  laboratory 
on  Earth.  There  will  be  only  24  hours  of  flight  time  on  ISS,  which  puts  an  onus  on  the 
SPHERES  team  to  present  the  astronauts  with  flight  code  that  will  run  correctly  the  first 
time. 

There  are  six  SPHERES  subsystems:  power,  software,  communications,  metrology,  avion¬ 
ics  and  propulsion.  Of  these  six,  software  is  the  only  one  whose  design  and  operation  will 
vary  for  different  guest  scientist  algorithms.  It  is  also  the  only  one  that  cannot  be  fully 
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tested  on  the  laboratory  air  table,  since  some  control  algorithms  cannot  be  tested  with  only 
three  degrees  of  freedom. 

6.1.2  GFLOPS 

The  GFLOPS  testbed  is  an  excellent  simulation  environment  for  SPHERES.  It  features  8 
networked,  embedded  computers  running  the  OSE  real-time  operating  system.  Loading 
separate  programs  onto  different  boards  mimics  the  flight  system,  where  separate  pro¬ 
grams  are  loaded  onto  different  SPHERES.  Because  OSE  was  designed  for  distributed 
applications,  implementing  communications  between  SPHERES  was  relatively  easy. 

GFLOPS  is  a  real-time  testbed,  so  it  is  well  suited  to  simulating  a  real-time  system  such  as 
SPHERES.  The  SPHERES  code  runs  with  the  same  timing  characteristics  as  in  the  flight 
system,  so  problems  related  to  timing  or  synchronization  can  be  discovered  through  simu¬ 
lation  on  the  GSS.  Also,  the  capability  of  measuring  processor  utilization  can  be  very 
valuable  for  measuring  and  comparing  the  efficiency  of  guest  scientist  algorithms. 

GFLOPS  is  further  enhanced  by  the  GFLOPS  Rapid  Real-Time  Development  Environ¬ 
ment  (GRRDE).  Because  GRRDE  was  designed  to  aid  development  of  spacecraft  flight 
code  and  simulation  of  distributed  satellite  systems,  its  features  eased  the  development 
and  testing  of  the  GSS.  Most  notably,  GRRDE  helped  in  establishing  communications 
links  between  software  modules  via  contracts.  Tools  provided  by  GRRDE,  such  as  atomic 
objects,  were  found  to  be  useful,  and  the  GRRDE  module  structure  helped  organize  soft¬ 
ware  modules. 

6.1.3  GFLOPS  SPHERES  Simulator 

The  GSS  solves  the  problem  of  testing  SPHERES  flight  code  in  a  zero-gravity,  6  DOF 
environment.  By  compiling  flight  code  into  SPHERE  modules  that  can  be  run  on  the 
GFLOPS  testbed,  it  allows  testing  with  multiple  SPHERES  of  guest  scientist  algorithms 
for  formation  flight,  autonomy  and  docking.  The  GSS  models  thruster  and  metrology 


Summary 


101 


characteristics,  and  propagates  the  dynamics  of  SPHERES  units.  It  can  handle  collisions 
and  docking  between  SPHERES,  as  well  as  user-applied  disturbance  forces. 

Users  can  monitor  the  progress  of  simulations  with  a  3-D  viewer  and  can  receive  teleme¬ 
try  or  send  commands  to  the  SPHERES.  Results  of  simulations  can  be  saved  and  played 
back  in  the  3-D  viewer  at  a  later  time.  The  OSE  real-time  operating  system  provides  tools 
to  analyze  the  processor  utilization  of  SPHERES  flight  code. 

6.1.4  Simulation  Results 

A  leader-follower  simulation  was  run,  where  the  leader  traced  out  a  square  profile  and  the 
follower  attempted  to  execute  the  same  profile  by  controlling  to  the  leader’s  state  (with 
some  offset).  This  test  demonstrated  thruster,  dynamics  and  metrology  simulation  as  well 
as  satellite-to-satellite  (STS)  communications.  It  further  allowed  us  to  test  measurement 
of  CPU  utilization,  yielding  the  interesting  result  that  the  follower’s  controller  interrupt 
used  much  more  processor  time  than  the  leader’s,  since  it  spent  time  waiting  for  state  data 
to  arrive  from  the  master. 

A  collision  simulation  showcased  the  dynamics  simulator’s  ability  to  handle  SPHERE- 
SPHERE  collisions.  A  passive  docking  simulation,  where  one  SPHERE  simply  ran  into 
the  other,  demonstrated  the  dynamics  simulator’s  ability  to  detect  and  simulate  docking, 
including  conservation  of  linear  and  angular  momentum.  Results  of  tests  of  a  cooperative 
docking  algorithm  on  the  MIT  SSL  air  table  and  in  the  GFLOPS  SPHERES  Simulator 
were  compared.  The  motion  of  the  SPHERES  was  relatively  similar,  but  the  data  indi¬ 
cated  that  measurement  reception  could  be  better  modelled  in  the  metrology  simulator. 
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6.2  Suitability  of  the  Simulator  for  the  Control  Interfaces 

6.2.1  Standard  Control  Interface 

The  GFLOPS  SPHERES  Simulator  is  best  suited  to  the  Standard  Control  Interface.  If  a 
guest  scientist  places  a  list  of  maneuvers  into  the  Standard  Control  Interface,  they  can  be 
compiled  and  run  with  no  modifications. 

6.2.2  Direct  Control  Interface 

The  Direct  Control  Interface  can  be  accomodated  by  the  GSS.  Since  the  controller  pro¬ 
cess  calls  the  SPHERES  control  code  without  modification,  any  changes  to  the  control 
interrupt  can  be  incorporated.  Changes  to  the  background  processing  can  be  accomo¬ 
dated,  but  would  require  some  effort.  Because  background  processing  in  the  SPHERES 
flight  code  exists  in  the  main  function  in  the  file  main.c,  along  with  various  commands 
executed  prior  to  the  background  processing  loop  that  are  not  compatible  with  the 
GFLOPS  testbed,  the  background  processing  code  has  to  be  manually  inserted  into  the 
background  process.  However,  this  is  generally  not  too  difficult  and  consists  of  cutting 
and  pasting  code.  It  is  not  expected  that  guest  scientists  would  make  changes  to  the  pro¬ 
pulsion  interrupt  or  the  communications  interrupt,  since  these  perform  lower-level  func¬ 
tions  that  should  be  common  to  all  guest  scientist  algorithms.  Changes  to  these  interrupts 
are  possible,  though  they  would  have  to  be  made  manually  in  the  SPHERES  wrapper 
code. 

The  cooperative  docking  simulation  (Section  5.5)  provided  a  good  test  of  the  adaptability 
of  the  GSS.  Because  the  control  code  for  the  algorithm  was  1.5  years  old,  it  did  not  follow 
the  Standard  Control  Interface.  The  majority  of  global  variables  had  different  names  or 
did  not  correspond  to  variables  in  the  Standard  Control  Interface.  Therefore,  the  coopera¬ 
tive  docking  simulation  was  an  example  of  a  use  of  the  Direct  Control  Interface.  Further 
complicating  matters,  metrology  processing  was  handled  entirely  differently  and  differ¬ 
ences  in  hardware  configurations  (eg.  numbering  of  thrusters)  were  present. 
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The  time  spent  modifying  the  SPHERE  module  wrapper  code  to  accomodate  the  coopera¬ 
tive  docking  simulation  was  logged.  A  total  of  4.5  hours  was  spent  getting  the  SPHERE 
module  to  correctly  compile.  For  someone  with  less  familiarity  with  the  GSS,  the  time 
required  would  have  been  much  longer.  The  differences  in  metrology  also  required  some 
changes  to  the  metrology  simulator,  which  are  not  included  in  the  4.5  hours.  Furthermore, 
several  days  were  spent  debugging  problems  that  arose. 

The  cooperative  docking  simulation  is  an  extreme  example  of  the  use  of  the  Direct  Con¬ 
trol  Interface,  due  to  the  magnitude  of  the  deviation  from  the  Standard  Control  Interface. 
Nonetheless,  it  illustrates  the  fact  that  testing  code  that  does  not  conform  to  the  Standard 
Control  Interface  can  pose  some  serious  challenges. 

6.2.3  Custom  Control  Interface 

The  GSS  is  not  well  suited  to  the  Custom  Control  Interface.  This  interface  has  essentially 
no  rules  associated  with  it,  so  it  is  not  difficult  to  see  that  the  GSS,  running  on  different 
hardware  with  a  different  operating  system,  cannot  have  the  flexibility  to  easily  incorpo¬ 
rate  Custom  Control  Interface  code.  That  is  not  to  say  that  custom  code  cannot  be  simu¬ 
lated  on  the  GFLOPS  testbed.  But  it  would  require  considerable  effort  to  change  such 
things  as  the  number,  type,  and  purpose  of  the  processes  that  exist  in  the  SPHERE  module, 
and  to  debug  problems  that  arise.  To  do  so  would  require  in-depth  knowledge  of  OSE, 
GRRDE,  and  the  GSS. 

6.3  Future  Work 

All  of  the  main  elements  of  the  GFLOPS  SPHERES  Simulator  could  be  improved  to  some 
extent.  There  are  features  missing  that  would  improve  the  accuracy  or  usability  of  the 
simulator.  These  areas  for  future  work  will  now  be  discussed. 
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6.3.1  Dynamics  Simulator 

One  inaccuracy  in  the  dynamics  simulator  is  that  it  does  not  take  into  account  the  decrease 
in  total  mass  of  a  SPHERE  due  to  decreasing  propellant.  Propellant  accounts  for  approxi¬ 
mately  5%  of  a  SPHERE’S  total  mass  [Miller,  2002],  The  amount  of  propellant  used  could 
be  kept  track  of  by  the  thruster  simulator,  since  it  knows  when  thrusters  are  turned  on  or 
off.  This  information  could  be  sent  to  the  dynamics  simulator,  which  would  incorporate 
this  effect  into  the  state  propagation. 

The  dynamics  simulator  has  some  deficiencies  related  to  collisions  and  docking.  These 
both  work  fine  up  until  the  point  that  two  SPHERES  dock.  After  that  point,  if  there  is  a 
third  SPHERE  present  in  the  simulation,  the  simulator  is  not  capable  of  handling  a  dock  or 
collision  between  this  third  SPHERE  and  one  of  the  others  that  are  already  docked.  None¬ 
theless,  this  could  easily  be  implemented. 

6.3.2  Metrology  Simulator 

The  detail  to  which  the  metrology  simulator  represents  global  metrology  signals  could  be 
improved.  In  particular,  the  metrology  simulator  currently  sends  distances  for  all  beacon- 
receiver  pairs  for  which  the  transmitter  and  receiver  angles  are  both  less  than  90°.  How¬ 
ever,  hardware  testing  has  shown  that  measurements  are  often  not  received  for  angles 
greater  than  60°.  If  enough  detailed  hardware  calibration  were  done,  we  could  character¬ 
ize  the  dependence  of  measurement  reception  on  transmitter  angle,  receiver  angle,  and 
distance,  and  build  a  probabilistic  model.  Doing  this  with  some  preexisting  data  was 
explored,  but  there  was  not  enough  variety  in  distances  and  angles  to  yield  a  useful  cali¬ 
bration.  Data  was  only  available  with  for  a  SPHERE  in  the  middle  of  the  laboratory  test 
space,  at  orientations  that  differed  by  90°.  Since  the  locations  of  the  receivers  are  symetric 
for  90°  rotations,  the  new  orientations  yielded  no  new  data. 

An  issue  that  is  not  addressed  in  the  metrology  simulator  is  that  of  loss  of  global  metrol¬ 
ogy  measurements  due  to  body  blockage.  Body  blockage  occurs  when  one  SPHERE  is 
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directly  in  the  path  between  a  beacon  and  one  of  the  other  SPHERE’S  receivers.  In  such  a 
case,  that  measurement  should  not  be  sent,  since  it  would  not  be  received  in  practice.  This 
capability  would  not  be  difficult  to  implement.  Since  the  positions  of  all  SPHERES  are 
known,  the  perpendicular  distance  between  each  SPHERE  and  the  line  connecting  a  bea¬ 
con  to  a  receiver  could  be  easily  calculated.  Then,  we  could  determine  if  this  distance  is 
less  than  the  radius  of  a  SPHERE.  If  so,  blockage  would  occur  for  that  beacon-receiver 
pair. 

A  further  area  in  which  the  operation  of  the  metrology  simulator  could  be  improved  is  in 
the  way  that  it  returns  measurements.  In  the  actual  SPHERES  flight  code,  the  CPU 
receives  IMU  and  global  metrology  measurements  in  the  same  way  as  STS  or  STL  com¬ 
munications.  The  data  arrives  as  individual  bytes  in  the  communications  interrupt.  This  is 
not  the  way  that  it  happens  in  the  simulation.  Here,  each  complete  IMU  or  global  metrol¬ 
ogy  measurement  is  sent  in  an  OSE  signal  to  the  SPHERE  background  process.  Changing 
this  to  be  compatible  with  the  format  expected  by  unmodified  SPHERES  flight  code 
would  require  some  effort,  but  could  clearly  be  done. 

6.3.3  Thruster  Simulator 

For  the  thruster  simulator,  better  models  of  the  thrusters  could  be  achieved.  Currently,  the 
nominal  thrust  level  for  each  thruster  on  each  SPHERE  is  assumed  to  be  the  same.  This  is 
not  accurate,  because  slight  differences  in  machining  the  thruster  nozzles  result  in  differ¬ 
ences  in  the  thrust  produced  from  each  nozzle.  It  could  be  valuable  to  be  able  to  set  the 
thrust  level  for  each  thruster  independently.  Another  issue  that  has  not  been  addressed  is 
encountered  when  two  SPHERES  dock  together.  Some  of  the  thrusters  on  the  docking 
panels  will  be  directly  facing  or  touching  the  other  SPHERE.  How  does  this  affect  the  net 
thrust  experienced  by  the  docked  SPHERES? 
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6.3.4  Communications  Manager 

For  both  STS  and  STL  communications,  there  is  a  maximum  bit  rate  of  19.2  kbps  that  is 
set  by  the  communications  hardware  [Otero,  2000].  For  STL  communications,  the  GSS  is 
not  able  to  support  this  rate.  However,  STS  communications  on  the  GFLOPS  testbed  can 
occur  at  100  Mbps.  To  make  STS  communications  more  representative  of  the  actual  hard¬ 
ware,  it  could  be  possible  to  limit  the  communications  bandwidth.  This  could  consist  of 
keeping  a  moving  average  of  the  rate  being  achieved  by  the  currently  transmitting 
SPHERE.  If  sending  the  next  byte  would  make  the  average  communications  rate  higher 
than  the  maximum,  then  we  would  wait  before  sending  this  byte.  To  avoid  changes  to  the 
SPHERES  flight  code,  this  new  functionality  should  reside  in  a  different  module.  The 
most  obvious  place  to  put  it  would  be  in  the  communications  manager.  That  would  mean 
routing  STS  communications,  in  addition  to  STL  communications,  through  this  module, 
which  should  not  be  a  problem. 

6.3.5  3-D  Viewer 

The  3D  viewer  is  well  suited  for  playback  of  short  simulations.  However,  for  longer  sim¬ 
ulations,  of  10  minutes  duration  for  example,  the  viewer  is  missing  some  features  that 
would  be  beneficial.  Often,  there  is  one  short  fraction  of  the  simulation  that  is  of  greater 
interest  than  the  rest.  An  example  is  docking,  where  the  few  seconds  leading  up  to  the 
dock  might  be  the  most  interesting.  If  one  wants  to  analyze  these  few  seconds  in  detail, 
from  different  angles  and  zoom  factors,  it  is  clearly  not  convenient  to  have  to  replay  the  ' 
entire  10  minutes  of  the  simuation  just  to  see  these  important  few  seconds  multiple  times. 
One  would  expect  to  have  a  "pause"  button  and  a  "play"  button  that  allow  the  user  to  stop 
the  playback,  view  the  scene  form  different  vantage  points,  then  start  it  again  when 
desired.  In  addition,  a  "slider"  control  that  allows  one  to  move  to  any  point  in  the  simula¬ 
tion  by  moving  the  slider  forwards  or  backward  would  be  very  useful.  Another  possible 
improvement  includes  drawing  the  global  frame  axes  to  help  the  user  visualize  the  test 
space  orientation.  Furthermore,  it  could  be  useful  to  have  an  optional  "trace"  function  that 
leaves  small  dots  along  the  path  traced  out  by  the  SPHERE,  to  allow  for  visualization  of 
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the  path.  Finally,  adding  some  identification  marks  on  the  panels  of  the  SPHERES,  in 
order  to  discern  their  orientations,  would  be  helpful.  This  would  be  especially  true  for 
docking,  where  one  wants  to  be  able  to  identify  their  docking  ports.  All  of  these  sugges¬ 
tions  could  be  implemented  fairly  easily. 

6.3.6  CPU  Utilization 

As  mentioned  in  Section  4.10,  we  cannot  draw  any  conclusions  about  the  absolute  proces¬ 
sor  utilization  on  the  flight  hardware  DSP  unless  some  type  of  calibration  is  performed 
with  the  same  code  on  the  GFLOPS  processors  and  the  DSP.  Even  then,  much  care  would 
have  to  be  taken  in  attempting  to  makes  conclusions  about  DSP  processor  utilization. 
However,  the  insight  gained  in  making  the  calibration  could  be  quite  valuable.  For  exam¬ 
ple,  consider  the  case  of  an  algorithm  for  formation  flying,  docking,  or  some  type  of 
autonomy,  that  can  only  be  tested  in  a  6  DOF  environment.  We  could  not  test  it  on  the 
MIT  SSL  air  table  and  might  not  be  able  to  tell  if  the  algorithm  can  run  safely  within  the 
constraints  of  the  DSP’s  performance.  This  might  also  be  the  case  for  an  algorithm  that 
we  can  test  in  3  DOF,  but  which  breaks  down  into  much  simpler  calculations  in  this  envi¬ 
ronment. 

Benchmarking  has  been  performed  before  with  the  GFLOPS  testbed  to  determine  the  rela¬ 
tive  running  time  of  various  floating  point  computations.  The  technique  commonly  used 
is  to  perform  the  same  calculation  a  large  number  of  times  (say  100000),  and  then  com¬ 
pute  the  average  time  for  the  calculation.  This  technique  could  be  easily  extended  to  mea¬ 
sure  the  running  time  of  a  longer  algorithm,  such  as  the  routine  used  to  determine  the 
SPHERE'S  state  from  global  metrology  measurements.  Performing  the  same  benchmark 
on  the  GFLOPS  and  SPHERES  hardware  would  yield  some  insight  into  the  relationship 
between  processor  utilization  on  the  two  systems. 
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Appendix  A 

GFLOPS  SPHERES  SIMULATOR 
SOURCE  CODE 


A.l  Dynamics  Simulator 


A.1.1  Sph_propagator.h 

#ifndef  _ SPH_PROPAGATOR _ 

#def ine  SPH_PROPAGATOR 

# include  <siglib.h> 

# include  " sph_int_obj  ect . h" 

#include  "Spheres_constants .h" 

class  CPropagator: public  CIntObject  { 
public : 

CPropagator () ; 
void  Re zero () ; 

void  SetDisturbance (double  dForce[3],  double  dTorque [3] ,  int  iDuration) ; 

bool  IsDisturbanceOn ( ) ; 

void  ZeroDisturbance {) ; 

void  ZeroTorques ( ) ; 

void  ZeroForces () ; 

void  SetlnvMass (double  dlnvMass) ; 
void  Setlnertia (double  dl [3]  [3]  )  ; 
void  Get Inertia (double  dl [3]  [3]  ) ? 
void  Getlnvlnertia (double  dl [3] [3]); 
void  SetPrincipallnertia (double  *  dl) ; 
bool  Inert ia_Is_Set ( ) ; 

void  SetGCState (double  dState [STATE_LENGTH] ) ; 
void  SetCMState (double  dState [STATE_LENGTH] ) ; 
void  GetState (double  dState [STATE_LENGTH] ) ; 

void  GetCMExtendedState (double  dState [EXTENDED_STATE_LENGTH] ) ; 
void  Ge tExtendedS tat e (double  dState [EXTENDED_STATE_LENGTH] ) ; 
void  GetPosition (double  dPos [3] ) ; 
void  GetPosVel (double  dPos[3],  double  dVel[3]); 

void  InterpToTime (double  t) ; 

void  InterpToTime (struct  TimePair  *tp) ; 

void  SetTorqueThrust (double  dTorque [3],  double  dThrust [3] ,  double  dTime) ; 
void  Get Fore eFromThrus ter s (double  dForce[3]); 
int  IntegrateToTime (double  dTime); 

//Debug  Methods 
int  GetNumLoops ( ) ; 

protected: 

//eta,  epsilon (0 , 1, 2) ,  omega (0 , 1, 2)  ,  pos(0,l,2),  vel(0,l,2) 
double  dXl [STATE_LENGTH] ; 
double  dX2 [STATE_LENGTH] ; 
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double  dX_Out [ S T ATE_LENGTH ] ; 

//Constant  pointers  to  first  elements  of  the  various  components  of  the  state 
double  *const  m_pdQuat; 
double  *const  m_pdRate; 
double  *const  m_pdPos; 
double  *const  m_pdVel; 

double  dWorstTol; 

double  m_dws [14] [STATE_LENGTH]  ; 

double  m_dC [24] ; 

double  m_dl [3] [3] ; 
double  m_dlnvl [3] [3] ; 
double  m_dlnvMass; 

//Position  of  the  geometric  center  relative  to  the  center  of  mass  (in  body  frame  coordinates) 
double  m_dGCpos [3] ; 

//3  body  frame  torques  (x,  y,  z) 
double  m_dBodyTorque [3] ; 

//3  body  frame  translational  forces  (x,  y,  z) 
double  m_dBodyForce [3] ; 

// 3  inertial  frame  translational  forces  (x,  y,  z) 
double  m_dInertialForce [3] ; 

//Disturbance  force  commanded  from  3-D  viewer  application 
double  m_dDistForce [3] ; 

//Disturbance  torque  commanded  from  3-D  viewer  application 

double  m_dDistTorque [3] ; 

double  m_dDi s turbS tart Time; 

double  m_dDisturbDuration; 

bool  m_bDisturbanceOn; 

void  normQ (double*  dX) ; 

int  CombinedDerivFunc (int  *n_eqn,  double  *t, double  *X,  double  *  X_prime)  ; 
int  Integrate (bool  bFromNow= false) ; 
void  ConvertThrustToInertialFrame () ; 
void  Calclnvl () ; 

//Debug  Info 
int  iNumLoops; 

private : 

}; 

#endif 


A.1.2  Sph_propagator.cpp 

#include  "sphjpropagator . h" 

#include  <math.h> 

#include  <string.h> 

#ifndef  _ NEED_TP_DEFN _ 

#def ine  NEED_T P_DE FN 

#endif 

# include  "gf lp_obt_conv. h” 

# include  "quick_vectors .h" 

/////// /CPropagator ////////////////////////// 

/* 

*  Constructor 

V 

CPropagator : : CPropagator ( ) 

//Initializer  list  to  initialize  constant  pointers 
:m__pdQuat (&dX_out [SIM_QUAT_1] ) ,  m_pdRate (&dX_out [SIM_RATE_X3 ) ,  m_pdPos (&dX_out [SIM_POS_X] ) , 
mjodvel (&dX_out [SIM_VEL_X] )  { 


int  i; 

m_dInvMass  =  INV_MASS; 


//Make  posvel  all  zero 
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//Need  a  valid  initial  quaternion:  eta=l,  epsilon=0; 
for  (i=0 ; i<STATE_LENGTH; i++) 

{ 

dXl [i] =0.0; 
dX2 [i] =0 . 0 ; 
dX_out [i]  =0.0; 

} 

dXl  [SIM_QUAT_1] =1 . ; 
dX2  [SIM_QUAT_1] =1 . ; 
dX_OUt [SIM_QUAT_1] =1 . ; 

//Number  of  state  elements 
iN=STATE_LENGTH ; 
iNw=STATE_LENGTH ; 

//Initialize  the  inertia  matrix 
int  j ; 

for  (i=0 ; i<3 ; i++) 

{ 

for  ( j  =  0 ; j<3; j+  +  ) 

{ 

m_dl [i]  [ j ] =0 . 0 ; 
m_dlnvl[i]  [j]=0.0; 

} 

} 

rn_dl C  0 ]  [ 0 ] = INERTI A_XX ; 
rn_dl [ 1 ] [ 1 ] = I NERTI A_YY ; 
m_dl [2] [2] = INERTI A_ZZ; 

Calclnvl ( ) ; 

for  (i=0 ;  i<3 ;  i++)  { 

m_dBodyTorque [i] =0 . ; 
m_dBodyForce [i]  =0 . ; 
m_dInertialForce [i]  =0 . ; 

} 

ZeroDisturbance () ; 
m_dDisturbS tart Time  =  0.0; 
m_dDisturbDuration  =  0.0; 

//Set  position  of  geometric  center  w.r.t  center  of  mass  in  body  frame  coordinates 
m_dGCpOS  [0]  =  -CM__P0S_X; 
m_dGCpos [1]  =  -CM_P0S_Y; 
m_dGCpos [2]  =  -CM_POS_Z; 

//Set  things  up  for  integrator 
dWorstTol=0 . ; 

X_dot= (DerivFunc)  ^CPropagator : : CombinedDerivFunc ; 


/* 

*  Set  3x3  inertia  matrix  of  satellite 
*/ 

void  CPropagator: :SetInertia (double  dl[3] [3]) 

{ 

memcpy (m_dl,dl, sizeof (double) *9) ; 

Calclnvl ( ) ; 

} 

/* 

*  Calculate  the  inverse  of  the  3x3  inertia  matrix 

*  WARNING:  ASSUMES  I  is  diagonal 
*/ 

void  CPropagator Calclnvl () 

{ 

SFLOAT  sflnvl [3]  [3] ,  sfTempI [3]  [3] ,  sf Index [3]  [3] ,  sf Scaling  [3]  [3] ; 

SFIX  sfRow [3] [3] ; 

siglib_numerix_SMXInverse ( (SFLOAT* )m_dl,  (SFLOAT*) sflnvl,  (SFLOAT*) sfTempI,  (SFLOAT* ) sf Index, 
(SFIX*) sfRow,  (SFLOAT*) sf Scaling,  3) ; 

int  i ,  j ; 

for (i=0 ;  i<3;  i++)  { 

for  (j=0;  j <3 ;  j++)  { 

m_dlnvl  [i]  [j]  =  sf  Invl  [i]  [j]; 

} 

} 

} 
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/* 

*  Get  copy  of  3x3  inertia  matrix  of  satellite 
*/ 

void  CPropagator: :GetInertia (double  dl [3]  [3]  ) 

{ 

memcpy (dl ,  m_dl , sizeof (m_dl) ) ; 

} 

/* 

*  Set  full  state  of  satellite 

*  CAREFUL:  This  sets  the  center  of  mass  state  directly. 

*  It  does  not  take  into  account  the  difference  in 
position  between  CM  and  geometric  center. 

*/ 

void  CPropagator: :SetCMState (double  dState [STATE_LENGTH] ) 

{ 

normQ (fcdState [SIM_QUAT_1] ) ; 
memcpy (dX2 , dState, sizeof (dX2) ) ; 
memcpy (dX_out, dState, sizeof (dX_out) ) ; 


/* 

*  Set  full  state  of  satellite  by  specifying  coordinates  of  the  geometric  center. 
*/ 

void  CPropagator: :SetGCState (double  dState [STATE_LENGTH] )  { 

SetCMState (dState) ; 

//Now  overwrite  the  posvel  info  to  take  into  account  CM  offset 
double  dTemp[3]; 

quat_rotate_out (m_jpdQuat ,  m_dGCpos,  dTemp) ; 

dX2 [SIM_POS_X]  =  dX_out [SIM_POS_X]  =  dState [SIM_POS_X]  -  dTemp [0]; 

dX2 [SIM_POS_Y]  »  dX_out [SIM_POS_Y]  =  dState [SIM_POS_Y]  -  dTemp [1]; 

dX2 [SIM_POS_Z]  =  dX_out [SIM_POS_Z]  =  dState [SIM_POS_Z]  -  dTemp [2]; 

//Take  into  account  that  the  body  frame  is  a  rotating  reference  frame, 
double  wxr[3] ; 

crossProduct (m_pdRate,  m_dGCpos,  wxr); 
quat_rotate_out (m_j?dQuat ,  wxr,  dTemp); 

dX2 [SIM_VEL_X]  =  dX_Out [SIM_VEL_X]  =  dState [SIM_VEL_X]  -  dTemp [0]; 

dX2 [SIM_VEL_Y]  =  dX_out (SIM_VEL_Y]  =  dState [SIM_VEL_Y]  -  dTemp[l]; 

dX2 [SIM_VEL_Z]  =  dX_out [SIM_VEL_Z]  =  dState [SIM_VEL_Z]  -  dTemp [2] ; 


/* 

*  Interpolate  the  state  vector  to  time  t,  starting  from  time  dTl 

*  RESULT : dT_out  set  to  t 

*  dX_out  interpolated  up  to  time  t 

* 

*/ 

void  CPropagator :: interpToTime (double  t) 

{ 

dT_out=t ; 

double  dTemp_t_int=dT2-dTl; 

intrp_ { &iN, &dTl , dXl , &dT_out , dX_out , &dTemp_t_int , &iNw, m_dws [0] ) ; 
normQ ( &dX_out [ S IM_QUAT_1 ] ) ; 

} 

void  CPropagator :: InterpToTime (struct  TimePair  *  tp) 

{ 

InterpToTime (tp2dbl (tp) ) ; 

} 


/* 

*  Propagates  the  state  vector  from  time  dT2  to  dTime 

*  Will  not  integrate  if  dTime  <  dT2 
*/ 

int  CPropagator : : IntegrateToTime (double  dTime)  { 
if  (dTime  >  dT2)  { 

dDelta_t  =  dTime  -  dT2; 

Integrate (false) ; 
return  0 ; 

} 

else  return  1; 

} 
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/* 

*  Propagates  the  state  vector  from  time  dTl  to  dT2  =  dTl  +  dDelta_t 

*  PARAMETERS :bFromNow=  true (reintegrate  for  rest  of  same  timestep) 

*  =  false (integrate  next  timestep) 

*/ 

int  CPropagator: : Integrate (bool  bFromNow) 

{ 

//Make  sure  thrust  takes  into  account  current  orientation  of  sphere 
//ilnd=l ; 

double  dOldCurTime; //time  from  which  we  are  integrating  from 

double  dCurTol=dTol; //current  error  tolerance  that  integrator  is  trying  to  maintain 
if  (bFromNow) 

{  //Reintegrate  for  rest  of  same  timestep 
dTl=dT_out ; 

memcpy (dXl , dX_out, sizeof (dXl) ) ; 
memcpy (dX2 , dX_out , sizeof (dX2) ) ; 

//Account  for  weird  convergence  behaviour 
ilnd=l ; 

memset (m_dws [0] , 0, sizeof (m_dws) ) ; 
memset (m_dC, 0 , sizeof (m_dC) ) ; 

//m_dC [6] =MAX_INT_FCN_EVALS ; 
m_dC [2] =0 . ; / / HMIN_ORB I T ; 
d01dCurTime=dT_out ; 

} 

else 

{ 

//Integrate  next  step 
dTl=dT2 ; 

dT2=dTl+dDelta_t ; 

memcpy (dXl,dX2, sizeof (dXl) ) ; 

//Account  for  weird  convergence  behaviour 
ilnd=l ; 

memset (m_dws [0] , 0, sizeof (m_dws) ) ; 
memset (m_dC, 0 , sizeof (m_dC) ) ; 

//m_dC [6] =MAX_I NT_F CN_E VAL S ; 
m_dC [2] =0 . ; / /HMIN_ORBIT ; 
dOldCurTime=dTl ; 
dT_out=dT2 ; 

} 

if  (m_bDisturbanceOn  &&  dTl  >=  m_dDisturbStartTime  +  m_dDisturbDuration)  ZeroDisturbance ( ) ; 

//move  X2  (of  prev  step)  to  XI 
//memcpy (dXl,dX2, sizeof (dXl) ) ; 

//integrate 
bool  bWorking=true ; 
iNumLoopS  =  0; 
while  (bWorking) 

{ 

dverk_(&iN,  X_dot , &dTl , dX2 , &dT2 , &dCurTol , &iInd,m__dC, &iNw,m_dws [0] ) ; 
iNumLoops++ ; 

if  ( i Ind==RK_ERROR__ERRREQ) 

{ 

//Retry  with  higher  TOL.  Rather  ad  hoc 

dTl=dOldCurTime ; 

dCurTol  *=  10 . ; 

dWorstTol=dCurTol ; 

memcpy (dX2,dXl, sizeof (dXl) ) ; 

ilnd=l; 

memset (m_dws [0] , 0, sizeof (m_dws) ) ; 

//memset (m_dC, 0, sizeof (m_dC) ) ; 

/ /m_dC [6] =MAX_INT_FCN_EVALS ; 

//m_dC [2] =0 . ; 

memset (m_dws [0] , 0 , sizeof (m_dws) ) ; 

} 

else 

{ 

bWorking=false; 

} 

} 

//dTl=dT2-dDelta_t; 

dTl=d01dCurTime; 
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if  (bFromNow) 

{ 

//  InterpToTime (dOldCurTime) ; 

} 

else 

{ 

/ / 6X2  is  copied  instead  of  dXl  to  cover  the  case  that  intrp_  is  never  used 
memcpy (dX_out , dX2 , sizeof (dX2) ) ; 

} 

normQ ( &dX_out [SIM_QUAT_1] ) ; //added  10/22/2002 
return  ilnd; 


/* 

*  Used  to  find  the  derivatives  of  the  13  state  variables. 

*  PARAMETERS :X=  current  state  vector 

*  RESULT :X_pri me =  set  to  derivative  of  X 
*/ 

int  CPropagator :: CombinedDerivFunc (int  *n_eqn,  double  *t, double  *X,  double  *  X_prime)  { 
double  dDistOn  =0.0; 

//Must  use  >=  and  <=  instead  of  >  and  <  or  will  crash 
if  (m_bDisturbanceOn)  { 
dDistOn  =  1.0; 

} 

//ROC  for  quaternion  (notation  for  euler  parameters) 

/ /eta_dot 

X_j?rime  [ S  IM_QUAT_1  ]  =  - 

.  5*  (X  [ S I M_QUAT_ 2 ]  *X  [SIM_RATE_X]  +X  [SIM_QUAT_3]  *X  [ S I M_RATE_Y ]  +X  [SIM_QUAT_4]  *X  [SIM_RATE_ 
Z]  )  i 

//epsilon_dot 

X_prime  [SIM_QUAT_2]  =  .  5*  (X  [SIM_QUAT_1]  *X  [SIM_RATE_X]  - 

X  [SIM_QUAT_4]  *X  [SIM_RATE_Y]  +X  [SIM_QUAT_3]  *X  [SIM_RATE_Z]  )  ; 

X_j?rime  [SIM_QUAT_3]  =  .  5*  (X  [SIM_QUAT_4]  *X  [SIM_RATE_X]  +X  [SIM_QUAT_1]  *X  [SIM_RATE_Y]  - 
X  [ S I M_QUAT_2 ]  *X  [SIM_RATE_Z]  )  ; 

X_pr ime [ S IM_QUAT_4 ]  =  .  5  *  ( - 

X  [ S I M_QUAT_3 ]  *X  [SIM_RATE_X]  +X  [SIM_QUAT_2]  *X  [SIM_RATE_Y]  +X  [SIM_QUAT_1]  *X  [SIM_RATE_Z]  )  ; 

//Rate  of  change  of  angular  velocity 
double  dTemp[3],  dTemp2[3]; 

siglib_numerix_SMXMultiply ( (SFLOAT* ) m_dl ,  (SFLOAT*)  (&X [SIM_RATE_X] ) ,  ( S FLOAT *) dTemp,  3,  3,  1)  ; 

crossProduct (&X [SIM_RATE_X] ,  dTemp,  dTemp2) ; 
int  i; 

for  (i=0;  i<3 ;  i++)  { 

dTemp [i]  =  m_dBodyTorque [TORQUE_X+i]  +  dDistOn*m_dDistTorque [i]  -  dTemp2 [i] ; 

} 

siglib_numerix_SMXMultiply ( (SFLOAT* ) m__dlnvl ,  (SFLOAT* ) dTemp,  (SFLOAT*)  (&X_prime [SIM_RATE_X] ) ,  3,  3, 
1)  ; 


//Rate  of  change  of  position 
X_prime  [SIM_P0S_X]  =X  [SIM_VEL_X]  ; 

X_prime  [SIM_POS_Y]  =X  [SIM_VEL_Y]  ; 

Xjprime  [SIM_POS__Z]  =X  [SIM_VEL_Z]  ; 

//Rate  of  change  of  velocity 

quat_rotate_out (&X [SIM_QUAT_1] , m_dBodyForce ,  m_dInertialForce) ; 

X_jprime [SIM_VEL_X] =m_dInvMass* (m_dInertialForce [THRUST_X]  +  dDistOn*m_dDistForce [0] ) 
X_prime [SIM_VEL_Y] =m_dInvMass* (m_dInertialForce [THRUST_Y]  +  dDistOn*m_dDist Force [1] ) 
X_prime [SIM_VEL_Z] =m_dInvMass* (m_dInertialForce [THRUST_Z]  +  dDistOn*m_dDist Force [2] ) 

return  0; 

} 


l* 

*  Normalize  the  quaternion  part  of  a  state  vector. 

*  PARAMETERS :X=  state  vector 
*/ 

void  CPropagator :: normQ (double*  dx) 

{ 

double  dNorm=l .  /sqrt  (dx[0]  *dX[0]  +dX[l]  *dX[l]  +dX[2]  *dX[2]  +dX[3]  *dX[3]  )  ; 
if  (dX [0]  <  0.0)  { 
dX [0]  *=  -dNorm; 
dX [1]  *=  -dNorm; 
dx[2]  *=  -dNorm; 
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dX  [3] 

*  = 

-dNorm 

{ 

dX  [0] 

*- 

dNorm; 

dX[l] 

*  = 

dNorm; 

dX  [2] 

*  = 

dNorm; 

dX  [3] 

dNorm; 

} 

} 

/* 

*  Check  if  the  inertia  has  been  set. 

*  RETURNS :true  if  the  Ixx  component  of  the  inertia  matrix  >  0. 

*/ 

bool  CPropagator: :Inertia_Is_Set () 

{ 

//return  (vect_mag3 (m_dl ) > . 0) ; 
return  m_dl [0]  [0]>.0; 

} 

/* 

*  Set  principal  inertia  values 

*  PARAMETERS :dl=  3  element  array  containing  principal  inertia  values 
*/ 

void  CPropagator : : SetPrincipallnertia (double  dl [3] ) 

{ 

m_dl [0] [0] =dl [0] ; 
m_dl[l]  [1]  =dl  [1]  ; 
m_dl [2]  [2] =dl  [2] ; 

} 

/* 

*  3  body  frame  angular  forces  and  3  body  frame  translational  forces 

*  dTime:  time  at  which  these  forces  and  torques  are  applied 
*/ 

void  CPropagator :: SetTorqueThrust (double  dTorque [3] ,  double  dThrust[3],  double  dTime) 

{ 

//First  propagate  the  state  up  to  now 
IntegrateToTime (dTime) ; 

//Now  save  the  torque/thrust  values  so  they  can  be  taken  into  account 
//for  the  next  integration 
for  (int  i=0 ;  i<3;  i++)  { 

m_dBodyTorque [i]  =  dTorque [i] ; 
m_dBodyForce [i]  =  dThrust[i]; 

} 

#ifdef  0NE_G 

m_dBody Torque [TORQUE_X]  =  0 . ; 
m_dBody Torque [TORQUE_Y]  =  0  .  ; 
m_dBody Force [THRUST_Z]  =  0 . ; 

#endif 

} 

/* 

*  Updates  the  m_dInertialForce  array  to  take  into  account  the  new  body  orientation 

*  Since  the  thrust  set  in  SetTorqueThrust {... )  is  a  body  frame  thrust  but  the  SPHERE 

*  might  be  rotating. 

*/ 

void  CPropagator: :ConvertThrustToInertialFrame ()  { 

quat_rotate_out (m_pdQuat ,m_dBodyForce,  m_dInertialForce) ; 

} 


/* 

*  Returns  the  position  of  the  geometric  center  of  sphere. 

*  Rgc  =  Rem  +  R (cm  ->  gc) 

*  whereRgc=  position  of  geometric  center 

*  Rem  =position  of  center  of  mass 

*  R(cm  ->  gc)=  vector  from  cm  to  gc 
*/ 

void  CPropagator : :GetPosition (double  dPos[3]) 

{ 

//Rotate  R (cm  ->  gc)  from  body  frame  coordinates  into  inertial  coordinates 
quat_rotate_out (m_pdQuat ,  m_dGCpos,  dPos) ; 
dPos [0]  +=  dX  out [SIM  POS  X] 


